SIerにいる若手開発者(プログラマ)が知るべき運用とは その2

以下の記事の続きです。

SIerにいる若手開発者(プログラマ)が知るべき運用とは その1 - のんびりプログラムのお勉強でも・・・・・・・

前回で以下を意識してコード書こう!でしめました。 今回は具体的に何が必要なの?を書こうと思います。

  1. いつ何が起こったか情報も何もなく、意味不明で何をしていいのかわからない非定型作業
  2. いつ何が起こったかだけはわかるが、意味不明で何をしていいのかわからない非定型作業
  3. 非定型ではあるが必要な情報はそろっており、頑張ればなんとかなる非定型作業
  4. 手順が整備されていない定型作業
  5. 手順が整備されている定型作業
  6. 何もしない

「いつ何が起こったか情報も何もなく、意味不明で何をしていいのかわからない非定型作業」から「いつ何が起こったかだけはわかるが、意味不明で何をしていいのかわからない非定型作業」へ

「いつ何が起こったか情報も何もなく」→「いつ何が起こったかだけはわかる」が変わっています。 ポイントは「いつ」と「何が起こった」です。 今回のメインテーマ。

「いつ」がわかるようにする

簡単にいうと何か起こったらすぐ運用者がわかるようにする!です。システム側から教えてあげないと運用者は気付くことができません。 つまり、先ほど書いた「監視」もしくは「人間が普段のコミュニケーションに使うツール」を使って教えてあげる必要があります。 プログラムレベルでいうと以下を気を付ける必要があります。

  • 想定外の例外などが発生した場合、必ず監視にかかるようにしておく必要があります
    • e.printStackTrace()やSystem.out(“エラー発生”)とかやっていると標準出力に出力されてしまう場合があります。Javaだと多くはloggerを使用することが多いです。そのloggerが出力したログを監視して運用者に伝えます。
  • そのうちITが進歩すればなんでも自動化できるようになるのでしょうが、限界があります。またお金の問題もあります。ごくまれに発生する事象に残念ながら高機能を作ることができません。その場合には運用者に「あとはがんばれ!」を伝えておくことも必要になります。
    • 多重障害に対する対応を自動化することは難しくこのパターンに入れておくとよいです。
5W1Hを明確にする

次は「何が起こった」です。 「いつ何が起こった」を明確にするため、5W1H(When、Where、Who、What、Why、How)を運用者がわかるようにします。 若干の拡大解釈しつつ、注意点を書きます。 「いつ」がわかった前提のため、ログにどんな情報を出すべきかが中心になります。 下記に例を書きますが、エラーのプログラムをする場合に5W1Hを意識してほしいです!

When

いつ! 上で書いた「いつ」と重なりますが、ここでいうのはログの時間です。多くの場合は単純に時間を出せばいいのですが、注意点は以下。

  • サーバが違う場合、時刻は同期がとれているのか?
  • サマータイムや国が違う場合の時差は考慮されているのか?

必要に応じて、ただサーバの時刻を出すのではなく、DBサーバなどから時刻を取得してすべてのサーバで出すなど工夫すると良いです。

Where

どこで! いろいろあるのですが、ソース部分のどこで起きたよ!を教えてあげる必要があります。 Javaなら例外発生時はStackTrace出せばわかります。 あとは自分でエラーにする場合。エラーログを出して終わりにしてしまったりするのをよく見ますが、IDを出したり どこでエラーを出したかを明確化するとより分かりやすくなります。

Who

誰が WEB APなどの場合、ユーザ情報を出力してあげると誰なのかわかります。BtoCの場合は難しいですが、社内システムなどの場合は、該当のユーザに連絡を取って謝ったりもできますw

What

何を。 これが考慮されていないログが非常に多いと個人的には思っています。 入力されたデータなどをわかるようにします。プログラムのバグの場合、特定のデータが来ると処理に失敗する場合があります。 その際に「エラーが出た!」だけ言われても解析することができません。 処理しようとしたデータがわかるような情報を出力することで原因解析が早くなります。 あと、例えば文字列の処理に失敗した場合にこの文字の処理に失敗したよ!というログを出しているプログラムを見かけますが、 これは「What」に答えられていない場合があります。 該当の文字はそれはそれでいいのですが、処理中のレコードのpkeyだったり、その他に紐づけられないとその文字でエラーになったのは わかりますが、どこから混入したのか追えなくなるので注意が必要です。

Why

なぜ? このエラーはどんな場合出得るのかを教えてあげます。 「エラーが出た!」だけでなく、このエラーが出た場合はDBとの接続に失敗しているから~を見てね、などです。

How

どうやって。 何をしようとしていたのか、わかるようにしておくことで原因解析が早くなります。 5W1Hだぜ!っていったけどHowって難しいw

「いつ何が起こったかだけはわかるが、意味不明で何をしていいのかわからない非定型作業」から「非定型ではあるが必要な情報はそろっており、頑張ればなんとかなる非定型作業」へ

1個上のいつを教えて5W1Hを伝えれば、運用者は調べることはできるようになります。 さらに1歩踏み込んで「何をしていいのかわからない」から「頑張ればなんとかなる」にします。 これはソースの書き方というより運用者が調べられるようにすることです。

主にはドキュメント。1つは設計書をきれいに書きましょう!ってことです。 さらに言うとこういうエラーの時にはこれを見てね!というのがあるとなおよいです。

意図しないエラーで発生頻度が低いものはここまで持ってくるのが限度だと思います。

「非定型ではあるが必要な情報はそろっており、頑張ればなんとかなる非定型作業」から「手順が整備されていない定型作業」へ

どんなエラーが発生するのか運用側に伝えてあげます。 エラー一覧みたいなやつですね。この状態だとエラー内容が頭に入っていたりして、 エラー見た瞬間にまたいつものか!みたいなやつです。

影響がないのはいいですが、オオカミ少年みたいになってしまうので、この状態で事象をとどめるのはやめて さっさと直すか次の段階までは進めてください。 ただ現場行くと意外とこの状態でとどまっている事象が多いです。 ずっとプロジェクトにいる仙人みたいな人が直したり、影響ないよ!って言ったりしているパターンです。

運用は人に依存するのは排除すべき!

「手順が整備されていない定型作業」から「手順が整備されている定型作業」

エラーなど運用作業に対して手順書を作成します。 シェルなどを作ってあげてでなるべく手順を簡略化するとさらによいです。

よく見かけるのがメモみたいな手順書ですが、最初はそれでもいいですが、 誰がやってもできる手順書を心がけるとよいです。

またエラー出なくても手作業が必要な場合はここまで落としてあげる必要があるため、 5W1Hなどを意識して運用者に情報を伝えつつ、手順書まで作成して誰でもできるようにする必要があります。

何もしない

手順書が作れるくらいだったらプログラマならそもそも自動化しろって話です。無理なのも多いですがw

まとめ

2回にわたってプログラマに知ってほしい運用を書いてみました。 私自身も若い頃は運用ってよくわからず、とりあえずリリース後に頑張ってくれる人たちだ!ってことで、 ほぼ故障みたいなやつを先延ばしして運用で頑張る!みたいにしてしまったことがあります。

実際には運用の方が期間が長くて、人も多く携わるし、お金もかかります。 これ誰かが対応するんだな~だったらこうしておこう!みたいな感覚を持ってプログラミングするだけでも だいぶ違うと思います!