SRE Session #1というイベントを開催。MonitoringとSLOについて発表や議論が行われました。

SRE Session #1 はじめました

% whoami

こんにちわ! 六本木で働いている ktykogm (k-oguma) です。
SRE Lounge というイベントの運営にも関わっています。

SRE Lounge/Session?

その SRE Lounge というイベントですが、以下を趣旨としていて、現在は 発表をメイン で行うイベントとなっています。

SRE Loungeの開催背景・趣旨
O'ReillyのSRE本にもありますようにSREはGoogleのDevOpsであり、必ずしも各社にとっての最適解ではあるとは限りません。
SREチームを持つ企業各社によって、SREとしての取り組みも様々なのが現状です。
一方向の講座形式の勉強会ではなく、 双方向に取り組みのシェアや課題の共有などができる、双方向のインタラクティブな場が必要と考え

https://tech.uzabase.com/entry/2018/01/26/200021

SRE本とはこちらのことです。

以前からBoard member同士で 「テーマを決めて、さらに双方向を熱くするためにディスカッションの時間を多くしたイベントも開きたい」 という話をしていました。

そのあたりの経緯について詳しいことは、 @chaspy_ さんの記事をご覧ください。

そんな流れで、SRE Lounge のスピンオフとして SRE Session というイベントをやることにしました。

記念すべき第一回目は、 2019/4/10 に Quipper Ltd. さまの会場にて、開催させていただきました。
あの、 スタディサプリ を作っている会社さんです!!
オープニングの会社紹介で グローバルに教育事業を進めていることが紹介されていました。
スマホを使って好きに沢山学べる時代で、今の子たちがうらy ..良い時代です!

さて、
前置きが少々長くなりましたが、そのSRE Session #1で行われた内容を共有します!

SRE session #1

SLO

記念すべき、第一回の初回プレゼンは、
minoru_tsuka さん / Yahoo Japan によるウェルカムトークとして、10min発表から始まりました!!

SLOってなんだっけ? それって誰のためのもの?
俺たちのSLOがあっても良いはず。

といったSLOそのものの捉え方や、

ユーザの期待値を考える。
ユーザの期待値が高まって設定しづらくなっていないか。

ユーザ目線(UX)からの考察と、その期待値の設計。

そして最初に述べられていた 「俺たちのSLO」という意味でも
チームにとってのSLOという目線で以下の感じたことやこれからSLOを設計する人たちのために共有してくださいました。

  • 自分たちが評価されるといった実感も大切
  • 考課者にとってのSLO
    • OKRだろうとMBOだろうとProjectの評価は出来る
      • しかし個人の評価は?
        • Projectよりも難しい
        • 議論のポイントである

他にはYahoo Japanさんで取り組んでいる事として、以下の紹介されていました。

  • オンプレからCloud構築およびk8s (Kubernetes) を構築しているので、metricsも取得しやすい
  • APMを持っている
  • SLAは開示していない

様々な視点でSLOを見ましょう。という内容で、
SLOってやっぱり設計も導入も難しい(技術面でも政治的にも) と思うし、それを導入まで持っていって機能することが出来たチームは評価された方が良いと思います。

その辺りも含めて、 SLOは、誰のためのもの? というのは今一度会社全体でも再考してより良いサービスに近づけていくことが大切だなと感じました。

SLOについてディスカッション

発表後は、ディスカッションの時間です。
まず、4人1チームに別れて自己紹介を軽くしてからSLOという議題に対しディスカッションを行いました。
そこで出てきた話としては以下のような話でした。

  • SLOは何をObjectとしているか
    • 障害/インシデント件数
      • 定量化している
        • リスクスコアを設計した
    • エラーバジェット
    • Performances
      • RPS/QPSではなく、Latencyで取得している
        • GoogleのSREと同じ
        • 200msで設定しているとのこと
          • [補足] Googleは100ms. どうして200msにしたのかは、今回時間が足りなくて聞けなかったので、次回お会いできた時にでも聞けそうだったら聞いてみたいと思います。
  • バジェット(予算)
    • バジェットを超えたらどうするのか/どうなるのか
      • 社長とは合意は取れているけど、実際はどうなるか不明
    • 超えないように点数の計測方法が調整された
      • 下手に忖度が働いてしまったのか
      • もともとObjectの設定が悪かったのか
    • 何度かは危なくなってはいるけど、タスクコントールしている
  • 本当に強制リリース停止措置が発動されたことはある?
    • 1.5年運用のうち、エラーバジェットを使い切って2回とめた
    • 一回バジェットがマイナスに行き過ぎてしまい、1Q丸ごと止めることになったことがある
      • 大変な思いをして設計しなおした
        • しかし、そのおかげで組織の中に意識改革が起こった
          • だから結果的によかったと思った
        • 品質をどのくらい重要視しているかが伝わった (お客様目線, etc
  • 改善は評価すべき
    • 改善が評価されないからSLOがうまく有効活用できていない
      • OKRに改善作業が殆ど入らないのも問題
        • 圧倒的に 機能開発 > (機能|品質)改善 になっている
    • ポストモーテムへの参加も評価すべき改善活動だと思う
      • 参加者や、インシデントコントローラーはもっと評価された方が良い

Monitoring

そして続いては 後半戦の、 Monitoringについて
spesnova さん / メルカリ によるウェルカムトーク、10min発表からスタートしました!

https://speakerdeck.com/spesnova/how-we-monitor-microservices-at-mercari-microservices-platform-team

普段メルカリでやっている監視事例を軸にMicroserivices の監視やObservabilityについて語っていただきました。

資料の中では

request_id をふってTrace出来るようにしている
Trace で問題箇所を把握して、logで原因を追求する
Logにも request_idを付けておき、それで追えるようにしている。

と説明されていて、追跡可用性(Traceability)を高める設計については普段から重要性を感じている人も多いと思うので、刺さる部分もあるのではないでしょうか。

他には

  • RED/USE method
    1. 基本的にREDから
    2. 次にUSE

と流れる。
Alert とSLIsもREDだと説明されていました。
これらの意味や内容については、ぜひ上記のスライドをご覧ください。

Monitoringについて、ディスカッション

続いて、またSLOの時と同じチーム4人でMonitoringについてディスカッションを開始しました。
続けて開始したので、チームに慣れてきた感が出てきたところで話題が変わったのでスムーズに開始されました。

  • 何使ってる?
    • New Relic
    • mackerel
    • kibana / Elasticsearch
    • kurado
    • Datadog
    • etc
  • Dashboardを誰が見るのか問題
    • 特定の人しか見ていない問題
  • あれこれ使っていて、集約した方が良いのでは?と議論している
  • ビジネスタイム以外は監視が弱くなっている
    • 特にB2Bがそうなりやすい
    • 心理的にも
    • 3交代 24H
      • ビジネスタイム時間以外の問題だから言うなとトラブルになったことがある
      • 勤務時間帯以外におきた問題は誰が見るのか問題
  • 監視対象が多い問題
    • 例: 22種類モジュール
      • 不要なものは減らす努力を開始している
  • Alertが埋めれる問題
    • 埋もれないように努力
      • AppとDBを分けて、どこの問題か把握しやすくする
  • Trace
    • 相関関係が見えていない
    • 1 request に対してのTraceが出来ていない
    • observabilityは考えていきたい
  • KPIが下がった事例
    • 調査に時間がかかってしまって影響があった
      • 障害原因
        • botだった
    • 課題
      • KPIはどこまで広めるか
        • 全社員が見れるようにしている
        • KPIの監視
          • 売り上げに直接関係する監視、Alertも取っている。
            • 飛んでくるとドキッとするやつ
          • e.g.
            • 5分単位でBuyの監視とか
            • 5分単位で問い合わせ件数を監視
              • 増えたらどこかで異常がおきているかもでAlertとか

その他のチーム では以下のようなことも話されていたようです。

  • 監視のツールを作っている
  • App開発でlogの出し方が悪い問題がある
  • grep, 落ちるエラーに対しては自動化
  • log is DB
  • logで正常を検知するには?
  • Monitoring toolの採択
    • 移行する場合は、移行するメリットを考える
  • 職人芸になっている問題
    • 属人化を避ける、システマチックにしていかないといけない
  • トラブルシューティングのナレッジも課題
    • いわゆるRun Book、問題管理
    • ssh login で対応もToilでしかない
      • それ以外の解決アプローチが必要
  • 狼少年的なAlert
    • 放置していいやつをどうやって直していくか
  • 分散トレーシング
  • log storage
    • 負荷対策が重要

全体を通して

他のチームで話をした内容も共有して議論を重ねて、楽しかったです。
続けていきたいなと思いました。

また、初回の発表という役を引き受けてくださった minoru_tsuka さん、 spesnova さん
お二人にとても感謝しています。
そして今後も楽しく学べる場をコミュニティの皆と作っていけたら幸いです。

お知らせ

次回の連絡や意見/情報交換は、 SRE LoungeのSlack でも行なっていますので、ぜひー!