こんにちは、インフラエンジニアの末廣です。
半年ほど前の記事「社内情報共有ツール」にあるように、Lodge をカスタマイズして社内情報共有ツール（以下、"Lodge改"）として利用しています。今回はこのツールを運用の現場で活用している様子をお伝えします。
解決したかったこと
運用の現場では障害対応のノウハウが属人化していて、障害対応できるメンバが限られているという問題がありました。trac の wiki にまとめたりしていたのですが、記事を書く敷居が高いのと、わざわざ検索しないといけないのとで、ノウハウの蓄積と活用が思うようには進んでいませんでした。
そんなところに Lodge改 が登場しました。これとサービス監視を連携させれば手軽に書けて障害時に参照しやすいノウハウ共有ができるのではないかと考えました。
社内情報共有ツールとサービス監視の連携
サービス監視の監視項目は HOST と SERVICE で一意に決まります。たとえば TECHSCORE なら HOST は "www.techscore.com"、SERVICE は "HTTP" という具合です。
そこで、次のように Lodge改 を更にカスタマイズしてもらいました。
- 記事に HOST と SERVICE の属性を指定できる。
- リクエストパラメータで "host" や "service" を指定するとそれに該当する記事一覧を表示する。例えば、"host=www.techscore.com&service=HTTP" とすると、HOST が "www.techscore.com" かつ SERVICE が "HTTP" に該当する記事一覧を表示する。該当する記事がなければ編集画面を開く。
サービス監視には Nagios を使っています。個々の監視項目の詳細ページ（extinfo.cgi) に手を入れて、上述のパラメータを指定した Lodge改 へのリンクを設置しました。（printf の羅列でベタに HTML が生成されていたので、この改造は難しくはないものの力技でやるしかなかったのは辛かったです。）
導入後
劇的な効果がありました。やはり手軽に書けて、監視システムから直接参照できるのは正義でした。
アラートが発報したらとりあえず Nagios の該当ページを開いて、Lodge改 へのリンクをたどる。
記事があればそれを読んで対応を実施し、なければ頑張って対応したあとで対応方法をまとめて次回に備える。
という運用がうまく回っていて、障害対応ノウハウの共有が進んでいます。
おまけ：魔法のタグ
我々の Lodge改 には「ないものねだり」という魔法のタグがあります。このタグを付けて Lodge改 の改善要望記事を書いておくと気の向いた開発者が実装してくれるかもしれないというものです。今回のカスタマイズも「ないものねだり」して実装してもらいました。「ないものねだり」してからリリースされるまで実質半日もかからない爆速ぶりで、リリースの連絡をもらったときには思わず椅子から飛び上がってしまいました。
