「トラシュー」ほどエンジニアが学べる場はない
運用をしていると、いろいろなことが起きる。問題は自分のコードとは限らない。ミドルウェアの問題や一時的なシステム負荷など、原因はさまざまだ。問題が発生したら、トラブルシューティング（以下、トラシュー）を行う必要がある。
PagerDuty プロダクトエバンジェリスト 草間一人氏は「トラシューはいいですよ。トラシューアニマルになりましょう」と呼びかける。アニマルというのは草間氏にとって称賛だ。トラシューが好きになり、喜びすら感じるようなエンジニアになってほしいという願いがこめられている。
実際、草間氏自身も「トラシューを糧に生きてきました。これほど学べる場はない」と力説する。多くが緊迫して頭脳はフル回転、集中力が高まるので知識は定着するし、新たな知見を得られる場でもある。複雑にコンポーネントが絡み合うなかから原因を探るので、システム全体の解像度が上がり、切り分けをしながら論理的思考能力も高まる。トラシューからしか得られない「栄養」がある。
「だからこそ、自分が開発したものは自分で運用しましょう。開発者もオンコールのローテーションに入りましょう」と草間氏は提言する。組織が大きくなると開発と運用を分けるように組織が役割分担しがちだが、それは本当に正しいだろうか。
約20年前にAmazonが提唱した「You build it, you run it」に象徴されるように、開発した人自らが運用に責任を持つようになってきた。Netflixでは「フルサイクルデベロッパー」、PagerDutyでは「フルサービスオーナーシップ」と呼んでいるように「そのテクノロジーに最も精通した人が製品開発ライフサイクル全体の責任を引き受けるような運用モデルにしよう」という考えだ。
知っておくべきは「障害のほとんどはデプロイによって引き起こされる」ということだ。Will Larson著『エレガントパズル』でも指摘されている。そのためトラシューするなら、サービスを最もよく知る人物、つまり開発者がやるのが最も早くて効率的と言える。
開発者が運用やトラシューすることの意義もある。まずサービス品質が上がる。トラブルが起きたら自分の身に返ってくるため、開発者は問題を起こさないことに（当然考えているだろうが、さらに）意識を高め、結果として品質が向上する。また障害対応が迅速化する。開発者は経緯も含めてシステムを熟知しているため、原因特定や復旧が素早くできる。
開発者が普段から運用に関与すると、ユーザーのフィードバックや本番環境での稼働状況も目にしやすいため、それを開発に反映しやすくなる。さらに運用担当に集中しがちだった深夜対応などの負荷が開発にも分散されて、組織全体で信頼性向上に取り組む体制や姿勢が育まれる。
ここで運用が手を焼いてしまうようなアンチパターンを挙げてみよう。例えばアプリケーションから必要なログが出力されていない、またはログが不明瞭だと、運用側はエスパーのような超能力を発揮して原因究明しなくてはならない。逆にログが多すぎると、今度は運用側は「目grep力」を高めて情報を探すことになる。ログの出力方法が不適切ですぐに見つからない、監視用のフックが存在しないなんてこともある。
これらは明確なアンチパターンだが、運用していくなかで「ああすればもっと良くなる」と気づくポイントは多くある。運用に関与するとこうしたアンチパターンに早く気づき、修正しようという意欲につながる。
開発と運用が分かれていると、やるべき改善に気づいたとしても自分のタスクになかなか入れにくく、改善が遅くなってしまう。そのため開発と運用が一緒だと、開発する、障害が起きる、トラシューする、改善するといったサイクルを早く回しやすくなる。
