ずっと読もうと思っていたけど読めていなかった「ウェブオペレーション」を読んだ．読んでたら週末終わってしまった！

2011年に発行された本だし結構古くなってるのかなとも思ったけど，全然そんなことなく，今読んでも目から鱗な知見ばっかりだった．確かにウェブオペレーションを取り巻く環境は広くなってたり，デファクトスタンダードな技術も推移して便利になってきているけど，マインドの部分は不変なものだなと感じた．

ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE)

作者: John Allspaw,Jesse Robbins,角征典
出版社/メーカー: オライリージャパン
発売日: 2011/05/14
メディア: 大型本
購入: 10人クリック: 923回
この商品を含むブログ (50件) を見る

ビジネスメトリクス

メトリクスって言うと Zabbix や Mackerel でサーバーリソースを監視することをまず想像するけど，サーバーリソースは正常だけどビジネス的に深刻な影響が出ていることにも気付くべきで，それをビジネスメトリクスと呼ぶ．

例えば，リクエスト数が異常に増減したり，収益が異常に増減したり，登録ユーザー数の伸びが止まってしまっていたり．

実際にビジネスメトリクスを監視できていたら防げた障害っていうのを最近体験していて，ビジネスとアプリケーション全体を俯瞰してメトリクスを可視化することの重要性を感じていたところだったので，耳が痛かった．

トラフィック急増

Yahoo! をなめるな！

で笑った．影響力のあるサイトから急に流入が始まったりするとリクエスト数が急増して生死を分けることがあるので，検知する仕組みが必要だし，もしビジネス的に予定していたイベントなのであれば，エンジニアとしては事前に知っておきたいなというのが本音かな．

頻繁にリリースを

「バッチサイズを小さくして継続的デプロイをするべき」と書かれている通りで，アプリケーションは頻繁にリリースするべきだと思う．第10章にルールが書かれていて，どれも当たり前のように思うけど，案外できてなくて負債を抱えたまま運用してるケースもあると思う．

ビルドとデプロイのシステムを自動化する
完璧に近いステージング環境を用意する
デプロイはできるだけ早くする（5分未満が理想的）

もしリリースに対して恐怖心を持っているチームがあれば，それは自動化で改善できるだろうし，リリース回数を減らしたいがために複数の feature を1度にリリースしようとしているチームがあれば，それは影響範囲を狭めるためにも feature ごとにリリースするべきと認識を改めてもらう必要がある．

障害が起きているのは機能ではなくプロダクトだ

障害が起きたら問題解決を再優先にすることが鉄則！特に前職で学んだ．犯人探しをしたって何も得られないし，シンプルにチームの雰囲気が悪くなる．名指しで責任転嫁するような場面に遭遇したら，必ず注意するようにしている．

必ず原因はあるし，複数の原因が起因してることもある．また障害対応の経験から学ぶことも多いし，ポジティブに考えることが重要だと思ってる．ユーザー目線になって考えればわかるけど，障害が起きてるのは機能じゃなくてプロダクトなんだよ！

自分のシステムに問題がないとしても、腕をまくって調べる態度が人を動かすのである。

きちんと振り返る

障害対応後の振り返りは重要だけど，特に TODO を洗い出しただけで曖昧になってしまうことはよくある．きちんと対応し切ってこそ障害対応完了と言えるし，チームとしても現実に向き合って時間を確保する決断が必要だと思う．

優れたアイデアを出しながら、実行しないチームをたくさん見てきた。そんなことでは、同じ問題に何度も何度も取り憑かれてしまう。

ただエンジニアの特徴として，対策にこだわり過ぎてしまうこともあると思う．どのレベルまで改善するのかはよく議論するべき．

ふりかえりのことを重く受け止めてしまい、必要以上に改善しようとするチームがあるが、近視眼的にならずに、ビジネス全体にとって意味のある改善をしよう。

アラート問題

障害は必ず起きるし，検知することの重要さを考えるとアラートを飛ばす必要がある．ただし，形骸化したアラートは相当に苦しいと思う．例えばこんな状況を実際に体験したことがあって，アラートの重要度が下がってしまうよなーなんて思ったりした．

「このアラートは定期的に出るので無視でお願いします」
「昨日と同じオペミスでアラートが飛んでしまいましたので無視でお願いします」

あ！来週は僕がアラート監視当番だ！僕が監視当番するとよく障害が起きるんだよなー！（都市伝説）

「夜中にアラートがあっただろ。2時に25通も来たんだぞ！原因は同じなのに25回も対応しなきゃいけなかったんだ！問題を修復したらグリーンになったけど、そしたら今度は4時だ。ping のエラーが1分おきに飛んでくるんだよ！」

まとめ

インフラエンジニアに限らず，むしろアプリエンジニアが読むべき！

プロダクトでウェブサービスを育てていく中で，ウェブオペレーションの重要さを共通の価値観として持ちたいなと思った．

そして自分の中でモヤモヤしてたんだけど，やっぱり僕はウェブオペレーションエンジニアになりたいんだ！って改めて気付いた．読み終わってハッキリとそう思う．今まではアプリ中心でなんとなーくウェブオペレーションのことも考えるような立場だったけど，これからは積極的に学んでガンガン経験値を高めていきたいと思う．いつやるの！今d (ry