導入
わたしは開発のエンジニアを経験した後、保守・運用のプロジェクトを数年経験しました。
保守・運用は実稼働しているシステムや環境に対する作業だからこそ、学べたことも多くありました。
今回はそれについて、少しお話できればと思います。
処理やDBの設計
保守・運用を経験すると、処理やDBの非機能要件を自然と意識するようになります。
なぜなら、保守・運用フェーズでは非機能要件が主役になるからです。
一口に 非機能要件 といってもなど様々ですが、例えばDB設計時の例を挙げると、
- 本番想定のレコード数と性能
- インデックスやパーティションの要不要
- 負荷に対する考慮
- 一定期間でクリーンするレコードやその条件
- etc...
など気にすべきことは多くありますが、私も保守・運用を経験するまで
これらに対する意識は低かったです。
既存のコードを読む力
保守は他社や別チームが開発したシステムを担当することも珍しくありません。
そして不幸な場合、有識者がいなかったり、プロジェクトの資料が古かったり、最悪ドキュメント類がない場合もあります。
その場合、ソースコードを解析するしかありません。
- インプット・アウトプット
- ロジックの中核部分
- etc...
コードの解読力は保守においてはもちろんのこと、他フェーズでも役立ちます。
私の場合は、保守案件の後に参画した現場で役立ちました。
そこでは独自のフレームワークで開発していましたが、それに関する資料は無く、その概要を把握するには既存のソースを解読するしかありませんでした。
保守でコードを読む力が鍛えられていなければ、1機能も満足に開発できなかったかもしれません。
実運用を意識したログ
実運用を意識する場合、処理の効率性やコードの可読性以外にも、ログの設定や出力内容も重要になってきます。
運用フェーズでは処理の正常/異常、開始・終了した時刻、全体の処理時間などの基本的な情報もログからしか取れません。
これらのログ出力を意識してないと、障害だけでなく簡単な問い合わせにも苦慮することになりかねません。
また、DBやAPIなど、外部への問い合わせに要した時間の記録も、ボトルネック特定などに有用ですし、些細な情報も処理のトレースに使えたりします。
ただし、ログの過剰出力はサイジング問題を引き起こします。あくまで、適切な出力とレベルの設定が大事です。
実装の際はログを意識してみてください。
原因を切り分け特定していく力
保守・運用は症状から原因候補を絞る仕事です。原因はアプリケーションに限らず、DB、OS、ネットワーク、ミドルウェアなど様々です。
障害等が発生したときはまず、その内容やログから切り分けを行い、原因を特定していくことになります。
例を挙げましょう。
PCと接続したイヤホンからYouTubeの音声が流れないとします。
考えうる原因を一旦以下のとおりとして、どう切り分ければ特定できるでしょうか。
- イヤホン
- PC
- ブラウザ
- YouTube
例えば、イヤホンを別のデバイスと接続し音が流れなければ、調査範囲をイヤホンに限定できます。
PCやブラウザに問題があった場合も同様です。
調査範囲を限定できれば、おのずと原因特定に近づくことができます。
この力や考え方は保守・運用フェーズ以外にも開発や実生活でも役立ちます。
最後
保守は本番作業や障害対応など、開発とは毛色の違う難しさがあります。
しかし、その経験は開発やマネジメントにも生かされると思います。
苦しいことも多いと思いますが、是非前向きに捉えていただければ、と思います。
ここまでお読みいただきありがとうございました。