システム運用で結構気をつけていること

私はいったい何者？

簡単に自己紹介しますね。ITエンジニア約5年ほどの者です。
最近はシステム構成を設計・構築していたり、運用そのものをやっていたり、その改善などをやっています。
もともとはソフトウェア開発もやっていたのですが、最近はその機会が減ってきました。

概要

システム運用に関して、個人的に気をつけていることをまとめてみました。
よかったらみてみてください。

なぜ書こうと思ったか

ソフトウェア開発の記事は結構あるものの、システム設計やその構築・運用のノウハウって意外とないよな〜
と日々思っていました。自分自身よくやっているのですが、参考になる記事の総数が少ないように感じていて、ちょっと寂しい思いがあったんですよね。
そこで...自分で書いてみよう！と思い立ちました。

個人的運用アンチパターン

ということで、気をつけていること...もとい、個人的に「こうするとよくないかもな」と思っていることを書いてみました。

1. ログを保管しない

サーバー上で色々なコマンドを実行すると思うのですが、コマンド実行だからといってログの出力を怠らない方がよいです。とても当たり前のような話に聞こえますが、
「ちょっとしたコマンド、スクリプトだから...」
と油断は禁物です。

• コマンドの羅列であれば作業ログは必ず記録
• スクリプトであればログの出力は必ずする、保管もきちんとする
  を徹底するようにしています。

なぜかというと、インシデントの際にトレースできなくなってしまうためです。
あとは、「どこまで何が進んだか」を明確にするためでもあります。

2. とにかくスクリプト化

あせって初期構築から運用の自動化を図るのも気をつけています。
理由は以下の通りです。

• 運用上の操作(デプロイやコンテナ格納・テーブルスキーマの変更・バックアップの復元)などの、リカバリーがあいまいな状態でのスクリプト実装は危険

デプロイなどのスクリプトで、あるサーバーへの反映はできたが、あるサーバーへの反映ができない...
ということもやはり想定すべきです。
特にテーブルスキーマの変更については、

• 再実行は可能か？
• 自動実行をする場合、既存テーブルの変更がかかってしまって大丈夫か？
  などの心配事がつきまといます。

まずは手動でのコマンド実行を丁寧に行い、マニュアルに落とし込み、そこからスクリプトに実装して慎重にテストするようにしています。

3. リカバリーの手順を確かめないこと

アプリケーションの開発もそうなのですが、

• 途中でエラーで実行が停止したらどうするのか？
• 再実行性は担保されているのか？
• データに歯抜けなどが発生したらどうするのか？
• イベントや時刻による起動を想定している場合、ワークフローが途中で止まったらどうするか？
  などの視点が案外抜け落ちやすい気がします。アプリケーション開発時には確かにアプリケーションの挙動そのもののテストはしますが、上記のようなモジュール間での異常系の確認が抜けやすい気がするんですよね。

ですので、

• バックアップの復元方法
• 再起動の方法
• 再実行性の確認
• バージョンの切り戻し手順
• 正常稼働するバージョンの確認
  などは、テストの文脈できちんと確認しておくべきでしょう。

4. アラートやメトリクスが少ない

こちらは個人的になるべく避けています。アラートとメトリクスは...
多ければ多いほど個人的に嬉しいです！！

CPUやメモリ、ディスク容量やロードアベレージなどの代表的なものももちろん大切ですが、

• バッチ処理の実行タイミングの通知
• デプロイの通知
• ファイルシステムのメトリクス
• データベースのログや一時テーブル用のストレージ
  などもぜひぜひ採取しておきたいところです。

あと、メトリクスは取るだけでは意味がなく、とても重要なのは
「どんな状態だと異常で、どのようなアクションが必要か」の定義と、
「メトリクスを定期的に確認する習慣」
があることです。

CPU使用率があがっていて、かつレスポンスが悪化していれば、再起動も選択肢に入るかもしれません。

5. アラートに対する明確なアクションがない

これはわりとあるあるのような気がしますが...アラートが来ても何をすればいいのかが決まっていない、という状況は避けるべきだと思っています。

例えばアプリケーションのエラーが発生している場合、まずはエンドユーザー目線でサービスがダウンしてしまっていないかを確実に確認する必要があります。
システムによって確認方法はさまざまだとは思うのですが、実際にログインするなどのアクションが明確に必要でしょう。

こちらの経緯としては、「アラートが来ても何をすればいいのかわからず、適切な復旧に手間取る」ということがあり得るためです。
エラーが起きているのにFQDNへのcurlだけで済ませるなど、対応者によって質がばらけてしまうことで、気づくべき問題に早期に気づけなくなる恐れがあります。

こちらは対処方針をまとめ、チーム教育を確実に行う必要があります。

最後に

技術ブログは初めてでちょっと勝手がわからないのですが、個人的によく気をつけている運用ノウハウについて書いてみました。

ソフトウェアやクラウド構築の記事があるのに運用関連の記事が少ないかも...と感じた皆様、
もしよければ一緒に記事とか書いてみてくださると嬉しいです。

今後の記事についてはCI/CDとか、自動化の文脈で使えるミドルウェアやスクリプトも紹介したいなと思っています。