BtoCで運用しているwebサービスは特性上、中々まとまったメンテ時間をとる事が難しいです。
来週夜間メンテが控えているので、初心に帰るつもりで記事化してみました。
なんとなくエンジニアになってから、メンテ要員に選ばれることが多い気がしなくもない。
1. 事前計画と準備
手順書の作成：
メンテナンスの目的、手順、スケジュールを明確にし、関係者に共有を行います。
スケジュール（というかメンテ時間）に関しては攻め攻めだと大体ろくな事がありません。
また、手順書に関しても時間的に高確率で頭が働いていない状態で挑むので、コピペで実行できる状態にしておくのがベターです。
バックアップの取得：
万が一のトラブルに備えて、必要があればバックアップを事前に取得しておきます。
リソースの確認：
日中に行ったことがない作業をする場合、必要なツールやアクセス権限が揃っているか確認します。
業務で使うPCを変えたばかりの時は結構な確率で何か発生します。
リスクの評価：
メンテナンスによるリスクを事前に評価し、必要があれば対策を考えます。
2. コミュニケーション
関係者への通知：
メンテナンスの日時、影響範囲、目的を事前に通知します。
取引先に関しては関連する人に連絡をお願いします。
緊急連絡先の共有：
トラブル発生時に迅速に対応できるよう、連絡先を確認します。
みんな寝てるので令和ですが容赦なく直電です。
3. メンテナンス実施
指定された時間にちゃんと出社する。
手順の遵守：
計画書に従って、手順を一つ一つ確認しながら進めます。
会社やチームの文化、メンテの目的に因って、
・テストの時間を多めに割いて不具合が起きる可能性を減らす
・最低限のテストをしてリリースし、なにかあったらすぐ切り戻す
を使い分ける感じですが、ここ最近は前者を選択する事が殆どです。
個人的には……内容による!!!!!
ログの記録：
作業中の変更や問題を詳細に記録し、後でのトラブルシューティングに備えます。
掛かった時間も残しておけば次回以降の計画を立てる際に役立ちます。
4. テストと確認
動作確認：
メンテナンス後にシステムが正常に動作するか確認します。
特に、主要な機能やサービスが問題なく稼働するかをチェックします。
hostsを書き換えたり、会社のIPだったらメンテナンス中でもフロントを確認可能だったり…等、色々と方法はあります。
担当者に確認：
必要に応じて、担当者に確認を依頼し、問題がないかフィードバックをもらいます。
…が、よっぽどの内容でない限り、夜中に確認するだけの人はいないです。
少なくとも今まで自分が携わった環境ではそうでした。
5. フォローアップ
資料のまとめ：
メンテナンスの結果をまとめて関係者に共有します。
今のげんではメンテナンス実施時の時間の記録等がそのまま該当します。
問題のフィードバック：
メンテナンス中に発生した問題や改善点を次回活かすために記録し、チームで共有します。
6. 過去にやらかしたTIPS
必要なカラム、テーブルを消す：
夜間メンテでよくあるやらかしシリーズ。
メンテ明けですぐ気付く！という内容は殆どなく、だいたい1週間後とかに発覚する場合が多い。
テーブル名やカラム名をロジックで組み立てて作って処理を書くのは本当にギルティ。
レビューで積極的に弾いていく。
テーブル定義の変更時に必要な設定の漏れ：
はい、わたしは既存テーブルのautoincrementを消したことがある重罪人です。
その節は申し訳ありませんでした。
特定のバージョン、文字コード等しか発生しないレアな不具合：
なにかのバージョンを上げた時によく引っ掛かる。
こういうのを完璧を目指して拾うようにするとテストが膨大になるので正直交通事故
実は正常だったのに上司（担当者）に鬼電した：
頭が働いてないから…ある。
普段から良い人間関係を築いていれば大丈夫な筈。
オフィスを最終退出する方法が解らなかった：
1人だったのでメンテ終わったら帰っていいのにも関わらず、みんなが出勤するまで待った。
最終退出者になったこともなかった。
悲しいね。
7. 最後に
プロダクトやチームの文化によって異なるところは沢山あると思いますが、何かの参考になったら幸いです。
一緒にメンテ作業をした人とは何となく絆が深まった感じもします。
それはそれとして今のプロダクトも個人的には3～4ヵ月に1回くらいで計画的にメンテ入れたい…。
なんとかなりませんか＞偉い人