PHP
Git
運用

[言語不問] 安定したシステム運用を目指してチームで取り組んでいること

初めに

どのチームも安定したシステム運用を目指して様々なことに取り組んでいると思います。
私のチームも少しずつ改善を重ねながら安定したシステム運用を目指しています。
今回は私のチームの取り組みを少し紹介したいと思います。

ログレベルによって対応の緊急性を明確にする

私のプロジェクトでは昔は

  • ERROR (slow down, メモリ使用量の増加, DB error, API連携失敗 etc)
  • INFO (validation errorの内容etc)

の2種類しかありませんでした。システムが大きくなるにつれてERRORの中でも対応が必要なものと対応が不要なものが混在してくるようになり複雑になってきたのでログ設計指針を見直しました。

Level 緊急度
FATAL 即対応
ERROR 即調査(翌日対応)
WARN 課題(近いうちに対応)
INFO 対応不要

PHP における PSR-3 では、さらに細分化され emergency, alert, critical, error, warning, notice, info, debug となっていますがそこまで細かくする必要はないかなと考えています。
またログフォーマットはgrepやawkで抽出しやすいものにする方がよいと思います。

これらの記事が大変参考になると思います。
ログ設計指針
良いエラーメッセージの書き方

エラーログをキャッチアップする仕組み

エラーが発生しているのに気が付くために、キャッチアップする仕組み(ログを監視するツール)を導入しましょう。
うちの場合はscriptをcrontabに毎分設定してWARN、ERROR、FATALが出力されたらメールを送信するようにしています。
最近だとslackに送信するでもよいかもしれませんね。

メモリ不足のトラブルに陥らないように、メモリ使用量をlogに出力

ある日メモリ不足でバッチが落ちたという経験はないでしょうか?
我々も年に数回そのようなトラブルを経験していました。
そこで70%を超えるとWARN logを出力させメールで検知させるようにしました。

ERROR 2018-03-06 00:00:00 [%s]Memory usage warning( mb/ mb). <- 85%以上使用
WARN 2018-03-06 00:00:00 [%s]Memory usage warning( mb/ mb). <- 70%以上使用
INFO 2018-03-06 00:00:00 [%s]Memory usage( mb/ mb). <- 70%未満使用

1リクエストあたりのレスポンスタイムをログに出力

10secを超えるとWARN logを出力させメールで検知させるようにしました。

ERROR 2018-03-06 00:00:00 [%s]Response slow down(x sec). <- 30sec
WARN 2018-03-06 00:00:00 [%s]Response slow down(x sec). <- 10sec-29sec
INFO 2018-03-06 00:00:00 [%s]Response(x sec). <- 10sec未満

log情報を視覚化する

  • メモリ
  • レスポンスタイム

splunkで視覚化させました。
メモリやレスポンスタイムの上昇を可視化できるので突発的なものか、じわじわデータが増えたことによるものか原因の切り分けに役立ちます。

リリースには2018BugFix-01や2018AddFunc-01などの名前を付ける

私のチームではリリースに対して必ず名前を付け、その下に各チケットにぶら下げて管理しています。こんな感じです。

Release name Ticket no
2018BugFix-01 prj-○○1
prj-○○2
2018AddFunc-01 prj-○○11
prj-○○12

これによる利点は、

  • いつのリリースでどの修正をしたのか追いやすい。
  • Gitのブランチ名に困らない

私のチームではこんな感じでブランチを切っています。

ブランチ ブランチ ブランチ ブランチ
master development 2018BugFix-01 prj-○○1
prj-○○2
2018AddFunc-01 prj-○○11
prj-○○12

GitのCommit logのフォーマットを作る

私のチームでは

2018BugFix-01 / prj-○○1 / 内容

のフォーマットでgitのlogを残すようにしています。理由としては、私たちは

  • confluence
  • JIRA
  • Bit Bucket

とアトラシアンの製品を使っており、'prj-○○1'とチケット番号を残しておけばBit Bucketが自動的にJIRAへのリンクを作成してくれるためこのフォーマットにしました。
しかし、このフォーマットはいつのリリースでどの修正をしたのかという情報が後から見て明確なので個人的にはかなりおすすめです。

ファイルをリリースする時には必ずGitのgit tagでtag付けする

リリース時に必ずgit tagしています。
状態を明確にしておくと何かあった時にすぐに戻せるので少し安心です。
私のチームではタグにはリリース名を指定しています。

command
$ git tag -a 2018BugFix-01 -m '2018BugFix-01 on Prod'

本番環境に対する作業は必ずlogを残す

本番環境のserverで作業をするときは必ずlogを残すようにしています。
logを残す目的は

  • オペレーションミスが起きた時に原因調査に使用する

  • 他の人へのknowledgeの共有

  • operation改善の材料にする

私のチームではLinuxのscriptコマンドを使用して作業ログを残しています。

command
# start logging
$ script ~/operation.log
...
# operation
...
# stop logging
$ exit

log出力の機能があるターミナルソフトもありますのでそちらを使用してもいいと思います。

トラブルシューティング用のドキュメントを作成しておく

システムを運用していると必ずトラブルに直面します。

  • Bug
  • バッチがメモリ不足で止まった
  • 人為的ミス etc

これらに備えてトラブルシューティング用のドキュメントを作成しておくとよいでしょう。
すべてのトラブルに備えるのは難しいと思いますので、

  • サービスの停止手順
  • DBのリストア手順
  • バランサーからの外し方

など代表的なものから作成していくのはどうでしょう。

みんながトラブルシューティングできるように訓練する

1人しかトラブルシューティングができない。。
こんな状況に陥っていませんか?その人がいない時にトラブルが発生したらぞっとしますよね。
そんな事態に陥らないように、トラブルのシナリオを作って定期的にトラブルシューティングの訓練をしましょう。

終わりに

もしわれわれの取り組みがどなたかのお役に立てれば幸いです。
うちはこういう取り組みをしているよという方はコメントを頂けると嬉しいです。