読者です 読者をやめる 読者になる 読者になる

かもめのはとば Re:[2]

やわらか系、モバイルとかアプリとか法律とか色々。

メンテナンスに対する考え方、呟きまとめ

後々のためにセルフまとめ。

サービスを止める=迷惑をかけること、です。
如何に不可避のものとはいえ、これは前提認識としてもっておきたいもの。
このお客さんにかける迷惑の最小化と、運営の都合を天秤にかけた上でメンテナンスは行うべきかなぁと考えています。

告知はお客様との約束
万が一時間の変更を行う場合も迅速かつ丁寧に。放置はもってのほかです。

前述の通り告知は約束なのです。その時間にあけると言った以上、お客様のためを思って早めにあけたとしてもその時間に期待して待っていた一番熱量の高いお客様を裏切る行為をやってしまう可能性があります。

あまりにもトラブルが続いたときにてすきで写経したことある。
そんなことしてる暇あったらチェックしてるほうが普通は賢明です :)

実に技量と判断力を問われる局面かなーと。
お客様ベースで考えると約束を破ることが確定している局面、なので如何にお客様ケアを最優先に考えるかでここの動きは変わってくると思います。
バタバタしてて後手に回りがちですが、いかにこまめに情報を整理して出せるかはとても大事。

事故った要素が分離可能であれば「とりあえず非表示処理」した上で解放することも選択肢に入れます。これはそれが可能かどうか担当者の知見とか判断力、開発者さんとの連携(とはいえだいたいこの段階だと開発さんは混乱してる)がいかに取れているかが重視されます。

前に書いたこともありますがどうしても試せない状況というのは出てきます。そういう意味でも要素や環境を小分けにする仕組みを作るときにどれだけ仕組んでおけるかっていうのは大切。
いきなりフルスペックを切り分けれない状況でぶつけると、事故ったときに収拾がつきません。

・スタートダッシュ時は不測の負荷が高い
・さらにユーザが多いと事故発生時の収拾が難しくなる(迷惑をかける方も増える)
・後ろが深夜になると運営側の心理的余裕が減る、金曜なら尚。

この辺りを考えると金夕なんかはかなり何かを出すにはネガティブな日だと思います。
しかしもう時間が決まってしまう広告やピークにピークを重ねるやり方(繁忙期に新要素をぶつける等)、他社との兼ね合い等でそういうアクションにでなければいけない場合もあるわけです…