大前提: 手作業をやってはいけない
病院で薬を棚から取ることを考えてみましょう。作業自体は高校生でもできるような簡単なものですが、似た名前の薬を取り違えたら死人がでるかもしれません。
開発に比べて作業は単純と見られがちですが、障害が起きたときの影響は同等、またはそれ以上です。今の段階では一見うまく回っていても、いつ爆発するかはランダムです。
リスクだけではなく効率を考えると手作業はもってのほかでしょう。
大前提: エンジニアがやってはいけない
自動化した！といってもエンジニアが対応していたらパフォーマンスは大きく変わりません。セルフサービスにして、要望を出す人が自らできるようにしましょう。発生源入力です。調整が消滅し、自分のことは自分で責任をとる健全な形になります。
手運用は機能不足を指しています。しかも需要が証明された開発要望です。ほとんどの機能開発が仮説検証から始まるなか、すでに証明されているのはありがたいですね。PdMにも相談しましょう。
＊システム運用はまた別
大前提: ☣︎本番環境は繊細☣︎
故意に本番を破壊することはないでしょうが、作業途中に壊してしまうことはあります。
個人情報を見なくとも、個人情報があるDBの近くで作業したくはないですね。
本番にログイン権限をつけているということは、乗っ取られたときに重大な被害を受けるリスクもありますし、重要参考人として疑いをかけられます。
とにかく、気軽な気持ちで触らないようにしましょう。アクセス回数を数えてみるのも一つの方法です。
☣︎特定病原体等取扱施設の実験室☣︎
こうやろう
実質的に開発です。設計〜リリース。小さな移行作業でもあります
計画する： 何をどの順番でやるか具体的に書き出す
アドリブではなく、細かく書いてみましょう。イメージトレーニングです。手順書を作りましょう
計画する： 影響を理解する
間違えて操作して仮にそのテーブルが壊れたときはどうなるのでしょうか？参照系でも重いアクセスで負荷がかかるかもしれません。従量課金のマネージドサービスならコストが大きくかかるかもしれません。
データ更新なら後続のサービスも変更の影響があるかもしれません。カラム直変更かつ共有DB状態なら別のプロダクトにも影響があるかもしれません。
設計と同じです。
計画する： ロールバックをどうするか
更新系なら戻せるようにしましょう。参照系でも負荷がまずそうなら停止できるとよいです。
計画する： 疎結合にする
作業AとBを同時にやる必要があるとリスクは上がります。なるべく分離する努力をしましょう。分離状況が一つの能力を指しています。
一つ手間をかけるだけでリスクが下がります
計画する： レビューしてもらう
詳しい人にレビューしてもらいましょう
計画する: テストする
開発環境で流れを試してみましょう。複雑な作業なら本番でもクローンや別の環境で検証しましょう。
一方、クローンや別の環境自体が障害を起こすこともありますし、別の環境だと勘違いして実本番で行ってしまうリスクもあります。
計画する: 時間帯を検討する
ユーザーに影響を与えないよう、夜間あたりに行うことが多いでしょう。一方、他のメンバーがいる時間が望ましいです。
うまく影響範囲を抑え、環境を分離できていれば何時でも作業できて安全です。今までのインフラ投資状況次第。
計画する: 立ち会い体制を検討する
影響度によってはユーザー利用増に合わせて立ち会いが必要です。特にtoBなら業務開始時間に立ち会っておきたいところ。深夜作業後に朝確認するなら、労務/体力面の考慮も。ハンドオフもありです。
計画する: どの権限を使うか
作業者が特定できるもので、なるべく小さい権限が望ましいです。アプリケーションのDBアクセス権限を流用するのは避けましょう。
ものによってはクオータリミットがかかり本番アプリケーションごと落ちます。
計画する： 分割リリースする
一度に全部作業するのではなく、段階を踏んでいきましょう。プロダクトと異なり、手作業や自作スクリプトはフェールセーフがありません。工数や認識の問題のため。危険なのでプロセスで防ぎたいところ。
計画する： スクリプトを開発するときは
実質ジョブの開発になるので、ジョブと同様のポイントを確認しましょう
- 進捗チェック
- 中間ファイルの生成
- 終了後の通知
など
実施する: コミュニケーション計画を立てる
場合によっては顧客通知も必要です
実施する: 作業を通知する
リリース関係のコミュニケーションチャネルで周知しましょう。万が一障害が起きたときのトレースのため
実施する: 作業メモを毎回取る
トラブルシューティングに必要です。次回の手順書にもなってうれしい、一石二鳥
また、システムレベルで作業ログを取る設定を入れておきましょう。シェルにせよ画面にせよ便利です。
実施する: メトリクスを見ながら作業する
負荷やエラーが出てないかを確認しましょう。
実施する: 作業結果を確認する
結果を確認するまでがゴールです
- 自分での打鍵
- 共通のスモークテスト/E2Eテストを準備しておくのが望ましい
- 他人への検証依頼ではなく自分で検証できる下準備をしておく
- メトリクス
- ユーザーの声(サポート)
実施する: 立ち会う
何もなければお疲れ様でした。
何かあれば当初計画通り切り戻しましょう。
実施する: 改善する
忘れないうちに行った手順、詰まったところをまとめ、次回のマニュアルにしましょう。
終わりに
作業の軽重に合わせ、提示した項目を取り入れましょう。本格的なものはシステム移行やジョブ設計に近いので、そのような内部資料にあたったり検索してノウハウを学ぶとよいです。
文責: 高木
