InfoQ ホームページ ニュース 高品質なアラートで開発者のオンコールを軽減する
高品質なアラートで開発者のオンコールを軽減する
2022年3月17日 読了時間 4 分
作者:
翻訳者
開発者にとって、オンコールはますます現実味を帯びてきている。アラートの改善によるノイズの低減、自動化、警告の削除は、オンコール作業の苦痛を最小限にするのに役立つ。
WayfairのスタッフエンジニアであるMario Fernández氏は、OOP 2022で開発者としてオンコールで対応した際の経験を紹介した。
企業が開発者を待機させるのは、他に選択肢がないからだとFernández氏は説明する。
ユーザーは今、完全な可用性を求めています。ウェブサイトを使って何かを注文したいのに、うまくいかなければ、もう来ないでしょう。その日すでにログオフしてしまった開発者にとっては残念なことですが、これが私たちの生きる現実なのです。
Fernández氏は、質の高いアラートを作成することでノイズを減らすことを提案した。うまく機能したもののひとつは、SLOに基づくバーンレートのアラートだ。
システムが遵守すべき指標(SLO)を定義することです。そして、その消費速度をバーンレートで測定し、エラーバジェットが危険にさらされたときだけアラートを作動させるのです。
ある程度の複雑さになると手作業では限界がある、とFernández氏は指摘する。例えば、バーンレートに基づくアラートには多くの変動要素がある。それを手作業で設定するのは大変な作業で、ミスが起こりやすい。
自動化することで、最新の状態を維持するための作業を軽減することができます。アラートの設定が多少間違っていても、そのアラートが数百もある場合、おそらく変更することはないでしょう。もし変更を自動的に伝達する方法があれば、実行する傾向が強くなるでしょう。
Fernández氏は、warningは悪であると述べた。warningとは「本当の」アラートを発するほどの問題ではないシグナルのことである。例えば、ハードディスクの容量が徐々に減ってきているが、まだ十分な容量が残っているようなときのように。
warningが多用されるのは、何かを見逃してしまうかもしれないという意識があるからだとFernández氏は言う。それによって多くのノイズが発生し、対処が必要な問題と待機できる問題の境界線が曖昧になる。
ほとんどのwarningを除去しても、シグナルが失われることはありません。ダッシュボードの点検や、ログを定期的に確認することで、デメリットなく同様の目的を果たすことができます。
InfoQは、Mario Fernández氏にアラートと自動化の使い方、監視を細かく調整するためのポイントについてインタビューした。
nfoQ:バーンレートのアラートはどのようにノイズを減らすのですか?
Mario Fernández氏:私はこの1年間、アラートについてさまざまな実験をしてきました。バーンレートに基づくアラートはfalse positive(偽陽性)とfalse negative(偽陰性)のバランスが良いので、非常に効果的です。必要なときに素早く反応し、かつ開発者に常にpingを打つようなことがないようなアラートを作ることができます。
SLOは、提供したいサポートのレベルに対してより体系的なコミットメントをするための方法です。ビジネス側と技術側はこの点では全く一致していないことが多く、オンコールローテーションの人たちはその代償を払うことになります。Googleはこの件についてAlerting on SLOsにたくさん記述しています。
InfoQ: オンコール業務の苦痛を最小限にするために、自動化はどのように役立つのでしょうか?
Fernández氏:自動化の原動力となるのが、Infrastructure as Codeです。変更をコードに反映させればメンテナンスの手間が省けます。ドキュメントと違って現場の実態とシンクロしやすいのです。
また、時間をかけてコードを抽象化し、他のユースケースに適合させることができるので、ベストプラクティスの普及にもつながります。ある問題を解決するのに時間がかかり、しばらくして別のチームがそれに陥ったのを見るのは、非常に悔しいことです。
InfoQ: モニタリングを常に微調整するためにはどうしたらいいのでしょうか?どのようなメリットがあるのでしょうか?
Fernández氏:システムは固定されているわけではありません。システムも、システムを監視するアラートも、時間とともに変化していくはずです。そうしないと廃れていきます。極端な例としては、廃止されたシステムのアラートを削除せず、そのアラートを受信してしまうということがあります。
継続的なチューニングはインクリメンタルな開発を促進します。一度の大きなリリースですべてを構築するのではなく、必要なものを少しずつ作っていくのです。実際に必要なものを作るので、無駄が少なくなります。その結果、過剰なエンジニアリングを防ぐことができます。しかし、それがうまくいくのは、継続的にチューニングすることを約束した場合だけです。
-
関連記事
-
関連スポンサーコンテンツ
特集コンテンツ一覧
InfoQ ニュースレター
毎週火曜日に前週のまとめコンテンツをお送りいたします。(日本語版は不定期リリース)25万人のシニアな開発者コミュニティーにぜひご参加ください。 サンプルを見る