システム運用アンチパターン読書会

 Posted on 2022年11月16日  |  1 minutes  |  160 words  |  morifuji

社内で読書会を開きました。

僕が4章と6章を担当したのでブログにも転載しておきます

4章 情報ではなくデータ

ほとんどダッシュボードについての話

まとめ

  • 利用者のことを考えてダッシュボードを設計しましょう
  • 利用者が値の良し悪しを知ることができるように、ウィジェットに文脈を与えましょう
  • 最も重要な項目が最初に目に入るようにダッシュボードを構成しましょう
  • 関連するウィジェットをグループに纏めて互いに閲覧・比較しやすくしましょう

思ったことやメモ

データと情報

  • データ：整理されていない生の事実

  • 情報：文脈や構造を与えること

    • 情報の表示方法に気を使え

ダッシュボードを作る上での考え方

  • 1.誰が見るか
    • ダッシュボードの対象者
    • ぼんやりしたままでは、ユースケースや文脈を考えにくい
  • 2.その人が何をどういうときに見るか
    • 見る人によって必要な情報は異なる
      • 同じ情報でも見る人によって深さを変える
        • 例えば、DB管理者には詳細なDBのCPU使用率など、レポート作成者には抽象的なステータス
  • 3.その人にどうやってみせるか
    • ダッシュボードに表示するGUIの話
      • ダッシュボードちゃんと作ったことない…
      • [参加者の意見] 機会学習のレポーティングではめちゃくちゃ使う
    • 折れ線グラフ
      • 困ったらこれを使うイメージがあった、しかし欠損値か0か分からないというデメリットは大きい
    • 面グラフ
      • 中間の層の推移がわかりにくいのであまり使いたくない…
        • [参加者の意見] そもそも内訳を見る際は別のグラフを使うべき！
        • [参加者の意見] なのであまり面グラフはあんまり使うケースない
        • [参加者の意見] 別名、「stacked bar graph」
    • 棒グラフ
      • 頻度が少ない
      • ほとんど使ったことない
      • デメリットは連続性が表現しずらい点
      • [参加者の意見] 折線グラフと同じ問題がある、しかし、棒グラフはそもそもイベントを図示するものなので、0=欠損値。なので問題ないことが多い
    • ゲージ
      • 見たことないw
      • 過去の推移が見えないので利用用途がだいぶ限られる
      • 面積あたりの情報密度は小さいが、¥最も小さい面積でなんらかの情報を伝えることができると思う
      • [参加者の意見] 利用用途はある。たとえば株価はゲージで表示したくなる、今の情報が大事なので
    • [参加者の意見] 他に散布図もあるよ
      • 点がある=データがあるってことなので、使いやすい

4.3.2 色による文脈の付与

  • しきい値線が赤色→その値を超えると異常事態
  • しきい値線が緑色→その値を下回っていると異常事態

無意識のうちに色で意味を識別していてすごいと思った

4.3.3 時間比較による文脈の付与

  • 時間比較は前と大きく変わってないというだけ、「問題はあるかもしれない」という意識は持っておかないといけない
    • 例えばちょっとずつ悪くなってるかもしれない

[参加者の意見] 閾値が動的でなければただの閾値で良いが、そうではない場合はこういうことをしないといけないと思う

4.4.2 読み手を導く

  • 「ダッシュボードに関する説明や目的・よく知られた異常値などを書いておく」

  • 段々とそのメモに知見やそのシステムのクセに関する情報が溜まっていきそう
  • 「読み手を導く」という意味ではドキュメント何にでも共通している気がした
    • 文脈がわからない人が見てもわかるようにするのは大事
      • スプレッドシートの先頭のシートにいきなり表を書かずに、説明や目的を書いたりするのと似てる気がする

4.5 ダッシュボードの命名

  • 読み手が関係するダッシュボードだけ見つけやすいようにフォルダ分けしましょう、という話。

  • 命名規則において、対象者や対象システムをファイル名に特定のフォーマットで入れるのは避けたいと感じてる（壊れやすいから）。できればタグなどで管理したいとは思った
  • 結局、ダッシュボードを追加・削除したときに、都度ダッシュボード全体を見てフォルダ分けや命名が不自然でないか、見にくくないかを確認して整理することが大事だと感じている
    • 実装コードやテストコードも同じ感覚
      • このフォルダ分け/命名に沿っておけばずっとOK、な訳ではない。コンテキストが広がったりドメインの意味が変わったりするので

6章

アラート発生によるオンコールおよびオンコールのローテーションに関する話、オンコールの経験ほぼなかったのでとても勉強になった

まとめ

  • アラートは、行動可能で、タイムリーで、適切に優先順位付けされている必要があります。
  • ノイズの多いアラートはアラート疲れを起こし、アラートを役に立たないものにしてしまいます
  • オンコール業務はスタッフの負担になります
  • オンコールによってエンジニアの生活をどれだけ見出してしまっているかを理解するために、オンコールの幸福度を追跡しましょう
  • エンジニアが根本的な修正を行い時間を確保できるようにオンコールのローテーションを構成しましょう

思ったことやメモ

6.1 苦労話

いつか病みそう、、仕事終わっていいのか終わったらまずいのかわからないのって結構ストレス…

6.2 オンコールローテーションの目的

  • オンコールローテーション、弊社でもいつか必要になる時が来るのかな…
  • 今まで緊急の問題で休日出勤したことあってそのときはすごい不快な思いをしたことあったけど、ローテーションが計画的でかつルールがあって見返りがあるならやっても良いなと思った
    • みんなはどう思ってるんやろう
  • 技術的な観点で重要な、1.メトリクスツール, 2.モニタリングツール, 3.アラートツール
    • どれもprefixにCloudWatchを付けることができる！
    • CloudWatchはここら辺全部カバーリングしてた
    • CloudWatchのBlackBeltちゃんと読みたいなと思った(読んでない)

6.3 オンコールローテーションの設定

  • 3つの役割を設定するように記載があった
    • プライマリオンコール担当者/セカンダリオンコール担当者/マネージャー
    • 案件にもよると思うけど3人体制は流石にリスクを過大評価しすぎちゃう？と感じた
    • 特にセカンダリオンコール担当者は緊張感なくなりそうな気がする
    • [参加者の意見] オンコール担当者への金銭的時間的コスト/障害の発生時影響度/障害の発生頻度をminimizeできるような人数を決めるべき
  • SLO（サービスレベル目標）
    • 確認までの時間、開始までの時間、解決までの時間
      • 開始までの時間がめちゃくちゃ大事だと感じた。定量的に決まってることで、最大限休日をエンジョイしやすくなる。オンコール担当者の幸福度に強く影響する気がする
    • サービスによってSLOは異なるが、最もSLOが厳しいサービスに引っ張られずに、発生頻度も考慮してSLOは考えたいなと感じた

6.4 アラート基準

  • アラートは文脈が重要
    • アラートには関連するドキュメントが必要
      • さっきのダッシュボードの話と似てる
  • いいアラートの条件

    • 行動可能である

      • 手順書のリンク貼るの賢い！ダッシュボードのリンク貼っておくのも便利そう

    • タイムリーである

      • 「問題が起きる前に気づけるよう閾値低めでこのアラートも作っておこう」みたいな思いつきのアラートは100%いいアラートではない

    • 適切に優先順位づけされている

      • 通知できる可能性が高い通知方法ってオンコールぐらいなんかな？
      • [参加者の意見] 自分にとってはTwitterのDMが電話よりも気付きやすい気がするw

  • アラートは削除してはいけないという考えが人々に植え付けられるからです.

    • 確かに作るの簡単だけど消すのめちゃくちゃ躊躇う気がする
      • アラートに関するドキュメントがあれば消しやすいんだろうなと思う
    • [参加者の意見] そういうマインドもあると思うが、消したことの責任がかかってしまうことが大きな原因だと思う
      • みんなで責任持ってアラートを消す運用にするべき

6.4.2 ノイズの多いアラート

  • 役に立たないアラートに遭遇したら、より適切なものに修正するか、完全に削除するか、どちらかにできるだけエネルギーを注ぐ必要があります

    • なぁなぁにするのは一番良くない（他の人も同じ経験をするので
    • アラートに限らず、ノイジーなものなんでもそうな気がする
      • 例えばノイジーなMTGは、MTGをなくすかアジェンダ変えるか
      • 確かになぁなぁで参加してるとじわじわ時間取られる

6.5

  • 4~6人、多くて8人
  • ローテーションが短すぎるとストレス、長すぎると緊張感がなくなる、
    • 緊張感がなくなると根本的解決に動こうとしなくなるっていう考えはなかった、目から鱗でした
  • インシデントはスキルアップのチャンス
    • めちゃくちゃ同意。死に物狂いだといろいろ記憶に残るし、愚かな原因を繰り返さないように身につく
    • けど、専門家ではない人が何の準備もなくいきなりオンコールの対応はできないので、ある程度ドキュメント化が必要
      • どうやってやるかは勉強できるけど、そもそも何があるかはドキュメントで共有しないといけない

6.7 幸福度の追跡

  • 要するに誰がどのぐらい緊急なアラートをどんな通知方法でを受けているかを追跡すること
    • 定量的に追跡するだけでなく、感情的な面でヒアリングしても良い気がする
  • オンコールの週には優先順位の高いタスクを振らない
    • 大事、そういう一息つけるときこそPJを俯瞰的に見ることができる。そう言うときには手順書作成とか厄介な問題への対処とか技術的負債の返却とか。
    • むしろオンコールあるかないか関係なくそう言う週が欲しくなった
tech  読書会  システム運用アンチパターン 

See also