はじめに
上司「ウチボリくん、運用設計任せていいかな？」
ウチボリ「Yes, sir.（即答、迷いのない瞳）」
半袖で粘るか、観念して長袖を出すか。毎朝の服装選びに少しの迷いが生まれ始めた、季節の変わり目。そんな時期に、運用設計を通して、僕のエンジニアとしての意識も「変わり目」を迎えることになった。
それから約2か月。慣れない業務に手探りで挑む日々を経て、なんとかリリースまで漕ぎ着けることができた。
決して楽な道のりではなかった。しかし振り返ってみれば、それは「コードを書く機能開発者」から、「システム全体を見るエンジニア」へと視座を強制的に引き上げてくれる、得難い機会だった。
本記事では、運用設計を通して得た学びを、忘れないよう年内のうちに記しておこうと思います。（※なお、プロジェクトの機密保持と、わかりやすさのために、本記事の内容は一部フェイクを入れたり、ぼかしたりしています。）
「手動での作業手順書」は、妥協ではなく立派な技術判断
これまで僕は、「手動での作業手順書による運用」に対して、「なぜ自動化しないのだろう？」と疑問を抱いていました。「エンジニアならば、自動化する技術も当然もってるし、したくなるだろう。」と思っていたからです。
しかし、実際に運用設計の当事者になってみると、僕はあえて「手動での作業手順書」を作成する選択をしていました。
理由は大きく以下の2つです。
- 発生頻度に対するコストが見合わない
自動化自体は可能であっても、それが「年に1回しか発生しない作業」の場合です。数日かけてスクリプトを書く、その数日があれば、手動で数年分の運用ができてしまう。「めったに使わない道具」を作りこむことは、正しい投資ではないと判断しました - 納期と必須要件を守るための現実的な選択
こちらは、「頻度は低くないが、今は工数が足りない」場合です。もちろん自動化すれば楽になるし、ミスもなくなります。しかし、その実装工数を捻出するために、システムリリース直前の工数を割くことは、現実的ではありません。そのため時には、「手動でカバーできるなら、泥臭く手動で乗り切る」という判断をしました
ここで学んだのは、費用対効果の視点です。開発やテストなどで、目の前の個別なタスクに取り組んでいた時は、品質だけを考えていれば十分でした。品質に納得がいくまでこだわった結果多少時間がかかっても、それは自分の時間を少し削れば済む程度の話だったからです。
しかし運用設計では、プロジェクト全体のコストを天秤にかける、より広い視野が求められました。
「自動化の方法はわかっている。しかし、コストに見合わないためあえて手動を選択する」
これは妥協ではなく、エンジニアとしての一つの立派な技術判断なのだと学びました。
そのログは、深夜3時にエンジニアを布団から引きずり出す価値があるか
開発担当だった時、正直に言うとログ出力は「雰囲気」でやっていました。処理が失敗してるなら、知らせなきゃいけないからとりあえずエラーログを出しておこう。そんな風に深く考えず、機械的に実装していました。
しかし、いざテストフェーズに入り、障害通知が流れるようになると、その考えは甘かったと痛感しました。
運用視点に立つと、当時の僕のログには2つの欠陥があったのです。
-
情報の欠如
ログを確認すると、「処理に失敗しました」という事実のみ。処理がどこでこけたの？ 影響範囲は？再実行は必要なの？そのログからは、運用者として一番知りたい「次に自分が何をすべきか」が全く読み取れませんでした -
緊急度の不一致
それ以上に反省したのが、ログレベルの不適切な設定です。アラートメールを受け取る運用者にとって、ログレベルはただのラベルではなく、その後の「行動」そのものを指します- Critical（緊急）：今すぐ起きて対応する必要あり。夜中の3時に電話で叩き起こされても納得できるレベル
- Warning（警告）：処理は落ちたが、リトライで成功した、あるいは業務影響があまりない。翌朝の確認で十分なレベル
もし、夜に緊急電話で叩き起こされて、ログを調査した結果「業務影響なし、翌朝対応でOK」だと分かったらどうでしょう。自分なら絶対キレてます。
「この機能は失敗してもユーザー影響がないから、通知はWarningでいい。Criticalで騒ぐほどではない。」
そう判断するには、実装段階で「誰が、いつ、何のために見るログなのか」という想像力が不可欠でした。ログとは、単なる記録ではなく、障害時に運用者がどう動くべきかを定義する、重要なプロトコルだと学びました。
さいごに
これまでは「どれだけ効率よく品質高く作れるか」ばかりを考えていました。しかし、ソフトウェアは作って終わりではなく、「どう作られたか」よりも「どう使い続けられるか」が価値の本質なのだと、運用設計を通して学びました。
「作業手順書」も「エラーログ」も、一見地味なアウトプットです。しかしそこには、システムを安定的かつ継続的に稼働させるための、エンジニアの意思決定が詰まっています。
もしまた上司に「運用設計任せていいかな？」と聞かれたら、次は迷わずこう答えます。
「Yes, sir.（やはり即答、しかしその瞳には強い思いが宿る）」