6章 アラート疲れ
アラートシステムに多くのノイズを発生させてしまい、それらはすぐに無視されるようになり、アラートが発生しているのが正常だと見られてしまうことです。このパターンはアラート疲れと呼ばれ、チームを深刻な燃え尽き症候群に導く可能性があります。
うちも CPU usage のアラート、鳴りっぱなしです
これはほんとうにあるあるなんだよなーっていうのを思う
以前に小さい新規事業のサービスローンチをやったことがあるけど、最初の1週間はまさに自分がオンコール対応していたのをだんだん思い出してきた。
6.1 苦労話
アラートがいつ来るかと心配で眠りが浅くなっていました
コンピュータにまるで仕えているかのようだ
こういうのも20年後くらいにはAIでの自動復旧ソリューションがふえているといいなぁ
リソース使用率だけでアラートを出すことの問題点は、そのアラートを受けても何をしたら良いかわからないことが多いと言う点です
(中略) アラートはバックグラウンドノイズの ようなものとなり、早期警報システムとしての効力を失います。
わかりませんよね。放置されがちですよね。
「CPU使用率がアラートに設定されがちなのはなぜ?」→「監視システムのデフォルト設定や簡単に設定できるからでは」
「AWS Aurora とかだと,CPU Usage とか気にしなくても良いかんじになっている」
配属早々は夜間対応を息巻いているひとも一ヶ月あれば面倒になっている
6.2 オンコールローテーションの目的
オンコールローテーションでは、特定の個人を一定期間、システムまたはプロセスの最初の連絡先として指定します。
(複数人かも知れないけれど) 個人、なんですね。
夜中に問題が発生しサポートが必要になった場合、助けてくれる人を探すために複数の家族を起こすのは最も避けたいことです。
それをやったら持続性がないですよね
電話やメールといった手段でエンジニアに通知できる必要があります。
(中略) 障害発生時の対応時間を向上させるためには、この通知が自動化されていることが重要です。
ツールが載ってるのうれしい。
6.3 オンコールローテーションの設定
オンコールローテーションがやっかいなのは、それが雇用契約のような正式な手続きを飛ばして、組織の中で自然発生的に生まれるからです。何も考えずにオンコールローテーションを設定すると、スタッフに大きな負担を強いる不公平なものになりがちです。
解決法を知りたい!!
サービス立ち上げ時の課題ですね(意識高い初期メンバーで引き受けて、整理しつつ事業の拡大とともに社員や外注へ徐々に整理する?)
面接でオンコールローテーションがどうなっているのかっていうの、自社サービス企業への面接でたしかに必須なかんじがある。とくにスタートアップだと顕著だろうな。
もしあなたがアラートを確認した後、何らかの理由でそれに取り組むことができない場合、その通知をそれに取り組めるほかのエンジニアに引き渡すのはあなたの責任です。
空中戦になりそうな部分は明確に原則的なルールを敷くのはほんとうに大事だよな。
はじめてひとりでオンコール対応解決の責任負うときが一番緊張した
燃え尽きないように設計するのが大事っていうの、開発でも当たり前なんだけど、不規則な時間や場所という状況であるオンコール対応だとより顕著になるってことだよね
そして最後の砦となるのがマネージャーです。
最後はやっぱりそうなるのですね。そうするとマネージャーが燃え尽きるのではという疑問がわきます。
「マネージャーやプロダクトオーナーの腕の見せ所。障害が起きても大丈夫なビジネスモデルから,徐々に拡大していくうちに体制を構築する」
アラート通知への応答時間のサービスレベル目標(SLO)を定義する必要があります
6.4 アラート基準
全体的にかなり人間社会って感じがする。(一度作ったアラートは1501回のうち1500回は無駄だったとしても削除しにくい心理になるとか)
すぐに調査する必要があると確信したときであるべきです。
事業影響とアラートを関係づけていないと何をもって調査すべきか判断が必要になる。
まずアラートには関連するドキュメントが必要です。それは、アラート自体に含まれる詳細情報かもしれませんし、誰かがアラートを受け取ったときに取るべき手順を説明する別のドキュメントかもしれません。
手順書がないと、その場で不明点とリスクのある操作をすることになりますから必要ですよね……。
ないときは,ちょっとづつ作っていくんですよね
参考になる過去のパフォーマンスがない場合もあるでしょう。……この場合、アラートの作成はおそらく時期尚早です。……データを取得しましょう。
ここめっちゃいい
6.4.1.1 複合アラート
直接、顧客に影響が出ているかどうかを検出できていれば十分に価値がありそうに思えるのですが、それに組み合わせて内部状態についてのアラートを出す必要はどこにあるのでしょうか。状態を把握するまでの時間が短縮できる利点はありそうですが、ダッシュボードを開いてから見られればいいような気がして。
「アラートの 3 つの要件を満たす (高める) ためにつかえるよ」
システムダウンのアラートを作成する際に……システムによってエンドユーザーのようにシステムにログインし、重要な行動や機能を確認する方がはるかに望ましいです。このようなタスクは……必要なものです。
納得。
推測ではなく重要なシグナル(実際につかってみて使えないなど)で判断するのって本当に大事だなーっておもう。
6.5 オンコールローテーションの配置
オンコールローテーションの人数が多すぎると、オンコールに参加する頻度が低くなってしまいます。オンコールにはある種のリズムがあり、変則的な時間帯に仕事をするだけでなく、システムの長期的な傾向を理解する能力も必要です。
参加していないと感覚が鈍るということですね。うーん。
長期的な目で見た時のオンコールの最小構成は、4 人のスタッフです。
4人で回せるのかな。
目安があるのはいいなっておもった。これはマネージャーとかは別ってことですよね。
1ヶ月に1回まわってくるくらいがちょうどいいっていうの、なるほどなーっていう気分。
なるほどー
本番環境に直接アクセスできる人の数を最小限にしたいという願望(の)……唯一の解決策は、トラブルシューティングで使用される最も一般的なタスクを自動化し、オンコールエンジニアが問題を適切にトリアージするために十分な情報にアクセスできるようにすることです。
これも納得。何を用意したらいいのかな。
CIサーバから、管理用の機能を呼び出せるようにするとか
6.6 オンコールへの補償
まともなオンコールを経験している人のほとんどは …… 補償の方針に満足しています
つまり、まともじゃないと満足しないと
アラートの回数が増加してオンコールの補償にかかる費用が増えてくると、より抜本的な解決策を講じてアラートが発生しないようにしようという考えが生じるでしょう
マネージャー側へのインセンティブだ。
これほんとうに大事。
収入が増加するにつれて、オンコールの金銭的補償で得られる現金よりも時間の方がはるかに貴重な資源となります
大事なポイントだ
人事部にオンコール補償の話し合いに参加してもらいましょう
現場でなしくずしに始まると、人事とか労務とかすっとばしちゃいますよね。
内部でやるにしてもすぐに消化しましょうっていうのは普通の代休でもそうだなーっておもった。30日以内とか60日以内に取得するようにしたらいいのかもな。
6.7 オンコールの幸福度を追跡する
全体的に納得したのですが、この追跡を誰がやるのかが見えなかったです。基本的にはマネージメントをする人の仕事だと思いますが、マネージャーに何でもやらせすぎなのでは……という気がして。
こういうのを管理するのが大変だからダッシュボードというかツールが必要になって、だからPagerDutyとかそういうのがあるんだなってあらためておもった。
6.8 オンコール担当中のタスク
6.8.1 オンコールサポートプロジェクト
使うときでないと改善・修正する必要に気付けず,一方でその場で直さないと忘れてしまう (チケット化しても放置されがち・文脈が失われがち) なので,オンコール中に直してしまうというのは納得しました。
オンコールを担当すると、ほかの多くの人がけっして持つことのない観点で稼働中のシステムをとらえることになります。
わかりみが深い。「なんでここはこうなってるの?」が湧いてきますよね。昔、仮に設定したものがそのまま……みたいなのが。
6.9 本章のまとめ
オンコールのためのツールの解説というよりはマネージャー?としてどのように取り組んでいくのかという感じでよかった。
言われてみてマネージャー視点が多いことに気付きました。
みんなからのコメント
実践する/伝えるためのハードルはなにか?
やらなければいけないっていう理由から、効果についてあまり語られない分野の1つであるため、工夫についてあまり会話されないことがおおいのかもしれない。(テストとかも少し前までそうだった
監視とオンコールは一歩づつ実現していくしかないのだけど、一歩だけ進んでも価値が見えにくいな……と思いました。
一緒に使うと良さそうなプラクティスやマインドセットはなにか?
ワーキングアグリーメント
ハードルの乗り越え方はなにか?実践/伝える方法はなにか?
書籍にもありましたが、ふりかえりやレビューでオンコールをしたことで気づいたことやセキュリティまわりの話をして、まわりは嫌な顔をしないとかなのかな。
ふりかえりが大事なの、ほんとにそう思いました。
どれくらい効果がありそうか?
大変だとしても納得できるレベルの仕事には落ち着きそう