日中メンテナンスの背景と考え方
はい、それではTimeTreeTechTalk始めていきまーす。
よっ、はい、よっ、相変わらずゆるっと始まりますけれども、今回はSREメンバーのみを迎えて
先日ちょっとツイッターで公開した、なんか日中にメンテナンスをどうしてやる、みたいなことに関する話をちょっと背景とか考えていることとか伺っていけたらなと思っております。
みゅーよろしくお願いします。お願いします。はい、背景としましては先月ですね、先月の末にTimeTreeの中でちょっと日中にメンテナンスをすることがありましたと。
そこでみゅーが社内でですね、こういう考えで日中メンテナンスしていきたいですということを共有したところ、それも社外に公表して自分たちのスタンスを明らかにしたほうがいいね、ということでですね、
スティーブがツイッターで公開してくれまして、たくさん反響をいただいたというのがありました。
日中にメンテナンスするっていうことで、ユーザー様からするとね、なんでこんな使うときみたいなことを思うかもしれないんですけども、こういう考えでやってます、みたいなことをちょっとみゅーから説明いただきたいなと思いますが、どうでしょうか、準備できてますかみゅー。
行きます。じゃあそうですね、ちょっと簡単にそうですね、なんで日中メンテナンスするの、みたいなところに答えるための背景というか考え方ってどんな感じですかね。
はい、そうですね、まず大きく2つありまして、まず1つ目は、これはもう個人的な思いというのも強いんですけれども、もともと僕、SIやで銀行系のシステムとかよく関わっていて、で銀行系だと必ず金融庁に届出を出した日時に計画停止をやらなくちゃいけないって決まってるんですけど、
でまぁそこからいろんなシステムを作っていく中で、ふとこう夜中にできれば休みの夜中にやるのが当たり前だよね、みたいな文化みたいのがあることに気づいて、僕もそう思ってたんですよね。
僕もそう思ってました。
そうなんですよね、でただ計画停止をやるっていうことはある程度こうリスキーな対応をすることが多くてですね、エンジニアも寝ている、多くのエンジニアも寝ている、ユーザーも少ない代わりに開発するメンバーも多く寝ている状況で少ない面数で意識が普段よりはっきりしていない中リスキーな作業をやっていくっていうのは
どんなものなのかっていうのをちょっと考え始めたのがこのタイムツリーに入ってからですね。
その頃は漠然と、例えばスティーブが書いてくれたと思うんですけど、止まる時間が、例えばその計画停止で影響する時間が少ないのであれば、結果影響するユーザーも少ないと仮定できるはずであれば、よりしっかり作業できる日中にやったほうがいいのではないかというふうにざっくり思ってた。
で、ここでもう一つタイムツリーに入って、最初はインフルエンジニアで入ったんですけれども、サービスが拡大成長していく中で、一人でインフルエンジニアとしてSREっぽいことはやってたんですけど、そういう肩書だけだと厳しいなということで、SREチームを立ち上げて本格的にそのSREに対してのインプットっていうのを始めたんですけど、その中にSLOだったりエラーバジェットっていう考え方があってですね。
だいたい30日間月のレンジでですね、ユーザーに対しての影響、例えばエラーの発生率、ある程度なんとなく決めた敷地を超えなければエラーを発生させてもいい。
そういうリスキーな機能を開発してもいいという。
そうですね。もちろん重大なインシデントにつながるものとかは、より警戒して行動しなきゃいけないんですけれども、よりアグレッシブなリリースだったりとかを実施してもいいのではないかという考えがちょうど書籍としてインプットが入ったんですよね。
そうなった時に大手のGoogleさんでさえこんな考え方を持って、もちろん体制とかもちゃんとしてるでしょうし、うちとは全然規模も違うんですけど、そういう考え方があって、何がタイムツリーにとっていいのかっていうのを考えた結果、ユーザー、Piですね、ノベルユーザーに対してどれだけ影響があるかっていうのを考えて、
タイムツリーの成長とSREチームの立ち上げ
より影響が少ないのであれば日中にやりましょうという考えのもとをやっていたところ、たまたまスティーブがそれに気づいて、最初あれですよね、ユーザーさんがツイートしてくれてたんですよね。なんで日中なんだろうみたいな。
そうですね。確かになぜどうしてこんな日中にやるんですかみたいなツイートが確かいただきましたよね。
実はそれってももともとやってたことなんですけど、そうやって気づいた方がいらっしゃって、それに対してスティーブがちゃんとした言葉で説明してくれたっていうことが話題になったきっかけっていう感じですね。なので、そういった背景で僕たちとしては行動しているという状況です。
そうですね。夜中に意識が朦朧とするっていうのもまさにその通りだし、半分寝ぼけながらやってるみたいな状態の時もないわけではないですからね。あと、これは切実な話ですけど、一回徹夜すると戻ってこないですよね。なかなかね。体調というか生活サイクルがね。
20代の頃は全然いけたんですけどね。
タイムツリーも最初の頃はそれこそ夜中の2時とか2時から4時までメンテ期間みたいな感じでやってたりとか、当然そういうこともやってましたけれども。
ミューが言ってくれたように、そこで何かあるとそこにいる人しか対応できなくて、一人で冷やせかけながらサーバーを直すみたいなこととかもあったりはしたので、こういうステートメントを出してくれることっていうのは本当にメンバーにとって嬉しいことだと思うし、ユーザーさんにとってはね、確かに日中だと困るっていうことも当然あると思うんですけど、
なんか我々としてそれ以上にさらなる大きい障害を起こすリスクっていうのもあるから、そこを考えた上でこの時間にやりたいっていうのはちゃんと出しておくっていうのはすごい重要ですよね。
お互いやっぱり人間なんでね、考えを表明しておくっていうのは大事なのかなって思いますよね。
ユーザーさんに対して100%の成功、エラーを出さないっていう、エラー率0%っていうのは理想なのかもしれませんが、
そこを求めていくとタイムツリーを運用していくことが非常に厳しくなっていく、極端に。
そうですね、やっぱりそうですよね。新しい機能を開発すると想定していないことがあってエラーが起こるっていうことは当然ありますし、
その機能改善をしていく中でメンテナンスに入れないといけないっていうことも当然あるので、
そこら辺はしっかりユーザーさんとも対話をして、タイムツリーをよりよく運営できるようにしていけたらいいなというのは、
メンテナンスの時間帯の選択
MEWも含めてというか社員全体としての思いですよね。100%を追い求めちゃうと何もできなくなりますから。
そうですね。
100%は目指すけどねっていうところですよね。
そうですね。
達成はなかなか理想に向かって永遠に走り続けるみたいなところではあると思いますね。
正直、何時にやるとかは非常に難しくてですね。タイムツリーは全世界にユーザーがいるので、いつやってもユーザーには影響出ちゃうんですよね。
そうですね。いつやってもどこかお昼なんですよね。
なので。
地球は真っ平であるべきなんですよね。
なので正直、そのタイミングに当たってしまったユーザーさんには本当に申し訳ないとしか言えないんですけど、
そこもタイムツリーを成長させていくっていうところで、ぜひご理解をいただいて、
共にいいサービスになっていければユーザーさんの使い心地も良くなっていくと思いますので、という感じですかね。
そうですね。何卒。
こういう特にあまり良くない表現かもしれないんですけど、
サーバーとかインフラの保守とかの側面って動いて当たり前っていう感覚がどうしてもあると思うんですけど、
そこの当たり前の先には人がいるわけで、
そういう人たちが健全に働くのもそうだし、過度にリスクを負って働くこともないように運営していきたいというのは、
タイムツリーのエンジニアのポリシーとしてやっていきたいですよね。
こんな感じですね。なんかあれ?なんかちょっとシリアスな感じになっちゃったな。
どうすればいい?
そうですね。
まあでも真面目な話ではあるんでね。
とはいえ、常に日中やるっていうことでもないってことですよね。
先ほどお伝えした通り、例えば1時間停止してしまうとか、
そういった場合はもちろんアクセス数が一番少ない時間帯を選ぶのが適当だと思っていますし、
本当に何秒とか1分かからないとかになってくると、
正直どこの時間帯でやってもほぼ変わらないので、
会社にとってベストな時間帯っていうのを選択していくっていう感じですね。
そうですね。
メンテナンス、そもそもやる前、計画立てるときに何時間ぐらいかかりそうっていうのはあらかじめ出しているので、
それを基準に日中やっても大丈夫だろうとか、
これはさすがにアクセスの少ない時間帯にやらないと影響出る人が多すぎるという判断はしているところですよね。
こういうことが当たり前になればいいなとむしろ思いますね。
ありがとうございます。
またお送りします。お疲れ様でーす。
![松浦シゲキの木曜回帰φ瑠[お仕事の時間管理とそのバランスについて]](https://image.listen.style/img/p0eH1QF17p3XMoAVtAMcHoljQW98rWfpZiE30LmI4ME/resize:fill:80:80/aHR0cHM6Ly9kM3Qzb3pmdG1kbWgzaS5jbG91ZGZyb250Lm5ldC9zdGFnaW5nL3BvZGNhc3RfdXBsb2FkZWRfZXBpc29kZS8zNzk5NDg3NC8zNzk5NDg3NC0xNzAwMTAyMjE5MDIxLTk0OThlYjE2NGRiZDMuanBn.avif)
