後々のためにセルフまとめ。
メンテナンスの話。継続してサービスをやる以上、必ず避けられないもの。ソフトウェア側が理由だったりもするし、ハードウェア側が理由だったりもする。原因もポジティブネガティブ色々あるけど、大抵はお客様に迷惑がかかってしまう。
— takashi kawai (@yrik) 2014, 8月 6サービスを止める＝迷惑をかけること、です。
如何に不可避のものとはいえ、これは前提認識としてもっておきたいもの。
このお客さんにかける迷惑の最小化と、運営の都合を天秤にかけた上でメンテナンスは行うべきかなぁと考えています。
で、メンテナンスをやりますよと言った場合、定期・定例のものを覗いて時間を見積もるんですがたいていは結構な余裕を持って見積もります。「メンテナンス延長のお知らせ」ほど冷めるものは無いからです。
— takashi kawai (@yrik) 2014, 8月 6告知はお客様との約束。
万が一時間の変更を行う場合も迅速かつ丁寧に。放置はもってのほかです。
で、余裕を持って見積もるが故にメンテナンス終わった段階ですぐ解放…してもいいんですけど、そうはいかない場合もあります。イベント開始時などスタートダッシュが発生する場合です。「誰よりも早く走り出すこと」をモチベーションとしてる人にとって、早め解放は萎え要素にもなるんです。
— takashi kawai (@yrik) 2014, 8月 6前述の通り告知は約束なのです。その時間にあけると言った以上、お客様のためを思って早めにあけたとしてもその時間に期待して待っていた一番熱量の高いお客様を裏切る行為をやってしまう可能性があります。
「早めに終わったけどあけられないとき」とかはたいてい別の仕事あるんですけど、手持ち無沙汰になると、細々としたチェック作業したり、大規模実装後だと祈ったりしてます。ぶっちゃけガチで祈ったことがあるぐらい怖い。
— takashi kawai (@yrik) 2014, 8月 6あまりにもトラブルが続いたときにてすきで写経したことある。
そんなことしてる暇あったらチェックしてるほうが普通は賢明です :)
「早く終わった余裕だー」とか思っている時に限って細かいチェックでポカ見つかったりするんですよね。そういうときはディレクターの危機対応力が本当に問われます。残時間、修正見積もり、対応フロー、場合によっては援軍要請。これを瞬時で片付けてメンテを伸ばすなら告知、伸ばさないなら処置開始。
— takashi kawai (@yrik) 2014, 8月 6承前、本当にちゃんとしたディレクターほど、不慮の場合にメンテナンスを伸ばすって判断とお知らせは早めに出します。なんとかなるって思ってる奴ほど直前告知になってお客様に不要なヘイトを溜める事が多いです。
— takashi kawai (@yrik) 2014, 8月 6実に技量と判断力を問われる局面かなーと。
お客様ベースで考えると約束を破ることが確定している局面、なので如何にお客様ケアを最優先に考えるかでここの動きは変わってくると思います。
バタバタしてて後手に回りがちですが、いかにこまめに情報を整理して出せるかはとても大事。
切り分けが上手い人であればあるほど実装要素の一部のみを開放し後回し可能なところはオンメンテ実装とかをやってのけたりします。担当者の技術的知見に依るところも大きいですね。
— takashi kawai (@yrik) 2014, 8月 6事故った要素が分離可能であれば「とりあえず非表示処理」した上で解放することも選択肢に入れます。これはそれが可能かどうか担当者の知見とか判断力、開発者さんとの連携（とはいえだいたいこの段階だと開発さんは混乱してる）がいかに取れているかが重視されます。
メンテナンスの時ってたいてい大きな要素の実装とかが多いんですが、あまりにも大きい物を入れる場合、先行して一部を切り出し実装してから本番に供えることもあります。いきなりフルでぶつけるってかなりのリスクがあるわけです。
— takashi kawai (@yrik) 2014, 8月 6「いや、リスクってそこテストしてるんちゃうんかい」って話は当然あります。テストは当然してます。けれどテストの環境と稼働する環境は負荷から何から全然変わってくるわけです。先にあがったスタートダッシュ待機勢のおかげで瞬間的には恐ろしい状態になりますし。
— takashi kawai (@yrik) 2014, 8月 6部分的にテストして出していく事が難しいかつ複数の運用環境がある場合は、メンテナンスの時間をずらし、より小さなプラットフォームでのテストを実施したりもします。携帯公式サイトの頃は特定のキャリアだけ数時間先に実装して様子を見る、といったらわかりやすいでしょうか。
— takashi kawai (@yrik) 2014, 8月 6前に書いたこともありますがどうしても試せない状況というのは出てきます。そういう意味でも要素や環境を小分けにする仕組みを作るときにどれだけ仕組んでおけるかっていうのは大切。
いきなりフルスペックを切り分けれない状況でぶつけると、事故ったときに収拾がつきません。
メンテの時間はかなりバッファを見て取ると書きましたが、そうはいかない場合もあります。トラフィックのピークタイムにかかる時、大規模実装後にタイアップや広告が走る時などです。こういうときはたいたい現場はぴりぴり、バタバタしてます。本当はそんな状態を作らないのが健全な運営なんですが…
— takashi kawai (@yrik) 2014, 8月 6リリース時、後ろ詰まりのメンテ時だけは普段ゆる系ディレクターの私でもだらけてるとキレます、はい。
— takashi kawai (@yrik) 2014, 8月 6・スタートダッシュ時は不測の負荷が高い
・さらにユーザが多いと事故発生時の収拾が難しくなる（迷惑をかける方も増える）
・後ろが深夜になると運営側の心理的余裕が減る、金曜なら尚。
この辺りを考えると金夕なんかはかなり何かを出すにはネガティブな日だと思います。
しかしもう時間が決まってしまう広告やピークにピークを重ねるやり方（繁忙期に新要素をぶつける等）、他社との兼ね合い等でそういうアクションにでなければいけない場合もあるわけです…
