生涯未熟

生涯未熟

プログラミングをちょこちょこと。

SRE NEXT2022に参加した！

SRE NEXT2022で様々なセッションを聴講した記録です！
自分用のメモをちょいと整理して書き起こしてみました🙇

https://sre-next.dev/2022/

 Day1

 How We Foster "Reliability" in Diversity

SRE NEXT 2020から2年ぶり2回めの開催👏

会社紹介
-> Topotal: sreを軸にしたスタートアップ
-> SRE as a Serviceをやっていて、お客さんとともにSREの達成を目指す。実際は組織のコンテクストを考えて最適な形で達成させる。
-> コンテクストの上でベストプラクティスを当てはめる。

 1. なぜ適切なSRE実践がむずかしいのか

SREの振る舞いは一つじゃない
ざっくりフェーズで信頼性の必要性は変わる
サービスの質でも変わるよね（人命がかかってるなど

 2. 適切な信頼性を定義し、育てていくための取り組み

5つのステップ。
4つ目の間接的に各チームにSREアンバサダーを制定して実践のお手伝いをする、というのがへぇとなった。

ポストモーテムのテンプレートを作っただけでは駄目だけどそれ以降の広めて浸透させるターンが大変。

組織の目に見えている問題は、目に見えない大量の要因が原因となっている
-> 組織の氷山モデル

先程のステップで話すと、1 -> 2のステップは5を見据えてやること。

企業全体を見てSREに必要な係数を洗い出す。
SREに大事なのは会社の方向性・サービスに関わる戦略・ビジネスを展開するためのリソース。
-> さらに抽象化すると企業方針・サービス・組織

MVV: それぞれの1行センテンス、それの備考を文章で書く。資料リンクがあればリンクも記載。
-> サイズ感としてはA4 5pくらいの軽い分量
-> これをもとにKPI制定。MVVにある言葉とつなげる作業
-> 氷山でいう下から上へのアプローチ

組織のマインドセットの変更
-> プラクティスの定着までやるということ

 3. 環境の変化に対してどのように取り組むか

ダイナミックケイパビリティ: 何が起こるか分からない時代なので、何が起きても対応できるようにしようという考え方
-> SREはこれを自然とやっているよねという話

多様性の取得に対してはこういったコミュニティが利用できるよね。

 QA

Q. 規模感によってやり方変わる？
A. 全てはできないがMVVはやってる。ただ、意思決定者にリーチできない、変化を拒む組織であるなど難しい要因があるなどの場面もあった。基本的な軸はぶらさずやっている。

 感想

SREってプラクティスをただやる職じゃなくて組織に対しての文化醸造などを含めた統括的な職責を持ってるよなーと改めて思った（小並感

 リンク

https://speakerdeck.com/nari_ex/how-we-foster-reliability-in-diversity

 1,000万人以上が利用する「家族アルバム みてね」のSRE組織は4年間でどのように作られてきたのか

 0->1フェーズ

3名からスタート
-> 6名に増えた

輪読会をやって更に踏み込んだ知識取得

ec2に入ってしていた作業とかを無くすようにしていった。

newrelicとかでアプリケーションのオブザービリティの強化はやっているが、よりログの基盤を強化している
-> 参加者の方のツイートでオブザービリティをo11yって呼ぶのを知った

スクラムで進めてる
-> スクラムイベントの時間を減らせるように改善をやっている
-> SREならではの割り込み作業はあるのでベロシティは重視しない（ポイントは重要なのでつける）
-> 属人性があるのは仕方ないので質問やドキュメントちゃんとしよう

参加者の方でみてねのこれ参考になったとつぶやいてる人がいた
-> https://team-blog.mitene.us/about-sre-team-7c2109450225

SREチーム内でk8s移行チームに分けた
-> 所属チームでも似たような感じで目的で短期的にチームを分けた経緯

 マネジメント

目標はざっくりチーム80%, 個人20%
1ヶ月テーマを決めて取り組み

 採用

公式とは別で採用ページ作ってる -> notionで作ってる
YOUTRUSTやMEETY使ってるのかー

技術面接: 架空のサービスの構成図を一週間で改善して持ってきてもらい、ディスカッション
-> 「面白そうなことやってる」という反応が多かった

SLI/SLO運用はまだなのでこれから

 感想

1ヶ月単位で取り組むテーマを決めてると聞いて、弊チームでも決めないとなーと反省。

 QA

Q. SRE組織が作られるきっかけは？
A. 経営層からのリクエスト

Q. SRE本以外に輪読したものは？
A. 他にはなし。ただSREの探求などは個々に読んでる。

Q. 求める人材は？（ちょっと聞き逃したのでこんな感じの質問
A. 最低限のインフラ知識、ネットワーク、Linux、クラウド、プログラミング経験を持っていること

 リンク

https://speakerdeck.com/isaoshimizu/sre-next-2022

 事業の成長と共に歩む、ABEMA SRE探求の歴史

 ABEMAの特徴

リニア配信が特徴
-> 障害時のインパクトが大きい
-> リクエストの波が激しい

配信系は通信トラフィックがネック
デバイス種別が多い

Production Readiness ChecklistをGitHubで管理
-> 開発サービスチームが自律的に動けるようにした

 SRE文化の推進

機能開発とSRE実施のモチベーションの違いで開発チームのリソースが確保できなかった。
-> ベネフィットの意識: 開発チームが何を求めているのか？を意識

小さなことからコツコツとやっていくべきだった。
-> 小さく初めて、小さく成功体験を重ねる

オンコールを放棄してシステム把握の機会を逃した。
-> SREチームがある程度までオンコールの対応をして、システムの把握をするべきだった

機能開発とSREの兼務は思ったよりも難しい。

 体制変更

一部既存SREを専属SREへ
-> SLI/SLOの先導などをやる
-> インシデントのオンコール対応への参加

 QA

Q. ネットワークトラフィック量への対応は？
A. 減らせるような対応を考えたら開発チームへ修正依頼を投げた

Q. アジャイルやってる？
A. 割り込みが多いので、アジャイルっぽくなってる

 感想

失敗話を聞けたのは物凄く貴重でした！

 1年間のポストモーテム運用と、そこから生まれたツールsre-advisor

ポストモーテムの統一運用をしている。
-> 他のPJの人から見るとわからないよねという観点から
-> 知見共有: 経験年数が長いメンバー以外もできるように

月刊ポストモーテムとしてまとめてポストモーテムを投稿している。
-> 定期的に投稿することで意識付け

ポストモーテムを書く基準を作る。
-> エラーバジェットを○○消費したら書きましょうみたいな

統一化により、プロジェクト終了しても存在し続けられるポストモーテムとなる。
-> 分析の結果、頻度の多い発生要因がプロジェクト毎に共通していることがわかった

チェックシートはトイルだよね。
-> エンジニアリングで解決
-> そして生まれたsre-advisor: よくある発生要因をチェックして指摘するツール
-> めちゃ良さそうだった！

 QA

Q. ポストモーテム書いてくれない人にはどうする？
A. あらかじめSREがわかるところを埋めて、残りは担当者に確認してもらったりで限定的な対応にしてあげる

Q. sre-advisorの出力結果はどのようにしている？実行頻度は？
A. markdown/テキストでペロッと出してる。頻度は月イチ。

Q. IaCの静的チェック検出やってないのはなぜ？
A. いっぱい指摘されて心が折れるのを避けたかった。自分たちでよくハマる問題だけを指摘したかった。

Q. エラーバジェットを指標にポストモーテム書く/書かないにした理由はなんですか？
A. 機械的に書く指標を決めただけ

Q. sre-advisorのチェック項目はどうやって追加していってる？
A. コードでベタに書いていってる

Q. 開発期間どのくらいですか？
A. 仕組み作りは一人で数日でできた。

Q. チェックリストはトイルはわかる、すべてなくせた？
A. 身内で出る分はすべてsre-advisorで置き換えられた。外部から来るのは・・・😇

 感想

ポストモーテムをきちんと活用できてるのはいいなぁ。弊社でも統一とかやってみたい。

 リンク

https://speakerdeck.com/fujiwara3/1nian-jian-falseposutomotemuyun-yong-tosokokarasheng-maretaturu-sre-advisor

 SRE チーム立ち上げから1年。気づいたら SRE っぽくない仕事まで貢献しちゃってる説

きっかけ: 組織規模と多様性がめちゃくちゃ増大した -> サイロ化などの問題が見られたので発足

 1年目にやったこと

  • SLI/SLO策定
  • ツール導入
  • ワークフロー制定
  • 各種支援
  • etc...

やっていく中でSREっぽくない動きも期待された。

  • テスト文化醸造
  • セキュリティ
  • コストダウン
  • etc...

IAM管理が辛かった。
-> めちゃくちゃトイル
-> Oktaで一元管理: GCPなどと連携

コスト最適化をした。
-> 事業拡大による適切なコスト増では？を探っていくのが重要
-> KPI単位でのコスト可視化した、ちゃんとコスパいい？のわかる化

ところで、これってSREのやること？
-> 定義の再確認
-> class SRE implements interface devOps
-> Opsを面で捉えるとちゃんとSREだよねという
-> 啓蒙することでSREチームの存在感は増した
-> SREなの？を整理することが大事

 2年目以降

啓蒙から実践へ
-> リーン、アジャイルなどの考え直し
-> Data Drivenを意識したSRE

 感想

コスト最適化の面で、しっかりと事業拡大のためのコスト増ですよというのを可視化しているのは良かった。
疑問に思ったら定義から再確認。大事。

 一人から始めるプロダクトSRE

様々なSREあるけどProduct SREの話。
色々やらなきゃいけないことあるけど一人だと難しいよね・・・

まずは現状、課題把握。
-> 無差別アラート発火問題: めっちゃエラー来るけど誰も何もしない
-> 原則に当てはめ、まずは通知要件見直し
-> SLI, SLOを制定し、SLOを脅かすエラーのみをアラート
-> チームへの共有を込めてダッシュボード作り（ダッシュボードがめっちゃちゃんとしてた）

SREとはなにか, あり方を伝える。
-> 一般的にSREは何をする人で、このチームのSREとしては何をするのか？

最終的にSREという単語を知らなくても開発者がSRE活動ができるチームが一番強い。

一人SREでどのようなSRE体制が最善か？
-> Enabling SRE: SREの自立支援部隊
-> Embedded SREかEnabling SREのどちらにするか
-> 発表者の方は様々な事情で専属でSREできなかったので、Enabling SREになった

様々な関係者の合意を取るのもSREの立派な仕事
-> 人に任せられるところは任せよう

スライド中にあったマーガレット・ハミルトンの話（最初のSREと呼ばれてる方）
https://www.wantedly.com/companies/studysapuri/post_articles/167052

 QA

Q. プロダクトごとのSREでコミュニケーションをとってる？
A. 全部が全部にSREがいるわけではないが、勉強会やったりはしている

Q. 既存のやり方に保守的なエンジニアいましたか？
A. （いるかいないかを聞き逃した...）いる場合、最初にどうしてこれをやるのがいいのか？などを伝えた

Q. 一人SREだとインフラ課題にとられて他のことができない
A. 優先度スコアで裁量を変えていって進めてみよう

Q. 人として信頼されることにやってることは？
A. やっていること、やらなきゃいけないことを宣言して解決していく -> 誰かが苦しんでることを解決しよう

 感想

Embedded SREだと「自分でガツガツ改善していくぞ！」ってなるけど、Enabling SREだとどうやってやってもらうか？を考える必要性があるのでより難しそう・・・
ただ、スケーラビリティを考えると組織上SREが少ない場合は有効そう。

 リンク

https://speakerdeck.com/vtryo/how-to-start-sre-in-a-product-team-all-by-yourself

 より意味のある監視を目指して、外形監視の有効活用

監視の要素

  • システム行動・状態データの収集
  • 収集データの可視化
  • 問題の検知・通知

よくあるアラート設計
-> 思いつく限りの怪しいアラートを緊急アラートとして通知
-> オオカミ少年アラートになる

CUJ: ユーザージャーニー（ユーザーが行う一連のアクション）の内、ビジネスクリティカルなもの
-> 対応として外形監視がシンプルで導入しやすい
-> Datadogを使った外形監視

Cloud Monitoringのpublic uptime checkちょっと気になった。

 LINEスタンプの実例紹介：小さく始める障害検知・対応・振り返りの改善プラクティス

読み上げソフトを使ったセッションがいくつかあったみたいだなー（このセッションも）。
聞きやすくていいんじゃないかなとおもった。
-> 話の間とかは考えるポイントかも

ヒロイズムなチームについて。
-> インシデントに対してエキスパートがすべてこなす
-> エキスパートのみが経験値を得て、皆がエキスパートへ頼り経験値を得る機会が０になる
-> Pros: エキスパートがやるので問題解決は早い。
-> Cons: 多様性が失われる。一人の能力値に限定される。

障害対応をReactiveからProactiveへ。
-> SLO Letterという手法
-> リバースエンジニアリングによる学びという側面

障害時訓練
-> 事前台本を渡してこなす
-> エキスパートの経験則を染み込ませる
-> 慣れてきたら台本無しで
-> やってみたら「とりあえずインスタンス落とそうぜ！」ってなってツッコミを入れる場面も

ポストモーテムレビュー
-> 200人（めちゃ多い...）を巻き込んだポストモーテムレビュー
-> 学びを最大化するためpreポストモーテムレビュー: 大規模な本ポストモーテムレビュー前にやる
-> ポストモーテムレビューの時間削減が出来た
-> LINEもポストモーテムは全プロダクトで公開状態にし統一化

preポストモーテムレビュー

  • 各自がコメントする
  • すべての疑問を解決されるまでやる
  • suggetionのディスカッション
  • 防止策の検討

=> 結果として、SRE本の28章の内容に則していた

 感想

めちゃんこちゃんとポストモーテムを扱っててすごい・・・
ポストモーテムレビューにすごい人数が関わってるのでコストのかけ方がすごいなーと聞いていた。

 QA

Q. 大規模レビューのスケジューリング大変じゃない？なんで同期的にやってるの？
A. 大規模レビューはLINEの超初期からの習わし。だんだん組織規模が大きくなった結果、こんな大規模になった。必須参加はリーダーのみで興味あるエンジニアは参加するという感じなので問題はない。

Q. SLO Letterでリバースエンジニアリングの時間を20分としている理由は？
A. 時間使いすぎたら時間を喰う悪いものとして扱われてしまう。なので、わからなかったらさっさと聞くために20分としている。

Q. インシデントごとにポストモーテムレビューやってる？
A. やってて全プロダクトでやってます。外部要因（GCPとか）だとやらない。

 Day2

 SRE bridge the gap: Feature development to Core API / 機能開発チームとコアAPIチームの架け橋としてのSRE

shopifyの前身：https://www.snowdevil.ca/
-> ウィンタースポーツのグッズ販売から始まった

開発組織とスケール・モニタリング・メンテナンスをする組織が全く重なっていなかった
-> そこから組織を見直し、開発組織とSRE組織が重なるようになった

インシデントのオンコール対応チーム（ShopifyではIMOCと呼んでいた）がSREとして進化。
-> ボランティアでオンコール対応はされていたが、さすがにあかんよねということでチームとして誕生
-> ソフトウェアエンジニアリングに対する各レイヤー層の健全性を見る組織になった

信頼性が脅かされるものはより強靭になるために必要である。
-> 創業者の言葉

フラッシュセール: セールの質によってスパイクが大きく異る
-> 特に大きいのがBFCM
-> 34,000,000req/minがロードバランサに飛ぶような世界観
-> 秒間56万リクエストか・・・

こういった巨大なトラフィックへの対応

オンコール対応はコアタイムで回るようにしている。
-> タイムゾーンが違うから出来るんだろうな〜
-> ChatOpsで対応できるようにしている
-> 後からのキャッチアップもしやすい

deeeeetさんがサーキットブレーカーについてリンクをつぶやいてた
-> https://shopify.engineering/circuit-breaker-misconfigured

３つのチーム

  • App devチーム: リーンを元にどんどん機能開発をしていくチーム
  • Core API devチーム: そのために必要なAPI開発をしていくチーム
  • SREチーム

組織拡大により専門性が生まれた。
-> それぞれの専門性が活かせるように３つのチームが強みを活かせる掛け算のチームを目指している
-> 架け橋としてのハイブリッドエンジニアが多くなればなるほどより強くなる

 QA

Q. Shopifyにおけるキャリアの考え方はどのようなものですか？
A. jungle gymという考え方で、キャリアラダーのような上に目指すキャリアだけではなく、横に広げるキャリアも同じように評価される -> 組織として多様性の獲得

Q. Shopifyの規模でGame dayをどうやっている？
A. サービス単位でやっているので１つの規模としてはでかくない（だいたい10人規模）-> SREはファシリとして参加

 AIOps研究録―SREのためのシステム障害の自動原因診断

運用データの観測法の研究
-> 観測収集したデータをAIと併せてSREに活かせるんじゃないか？と研究

SREの探求の18章にも「SREのための機械学習入門」があるらしい（未読

AIOpsの起源は1980年代。1990年代からはオンラインにおける研究論文も増えた。

論文の分類

  • 障害予測
  • 障害検出
  • 原因分析

障害原因を答えるほうが難しいよね？と考え、そちらの研究を開始

 自動化構想

大量のアラート・大量のメトリクスがあると・・・
-> 認知負荷増大！
-> 大量のアラートは症状と原因を一緒くたにアラートするから起こるのでは？
-> SLOに基づくアラートなどをトリガーにAIで原因診断
-> 既に研究はされてる: CauseInfer, Microscopeなど

アラートから原因となりそうなメトリクスを利用した因果グラフを生成
-> 因果グラフ・メトリクスのランキング化という研究も発展的にあった

未解決領域はどこか？
-> システム観測された全てのメトリクスを入力として因果グラフを生成するのはどうか

処理時間などが問題であったが、事前に時系列で直近データを分析かけてからやれば多くのメトリクスでも処理できそう
-> オペレータの認知処理をトレースするよう進める

時系列異常パターンをグラフ形状で分類する。
-> これを通常グラフと異常グラフで見比べる
-> K-S法でやったが、色々問題も・・・

https://www.coronasha.co.jp/np/isbn/9784339024913/
-> こちらの本に書かれている異常検知手法でトライ

自己回帰モデルの利用
-> 過去の値から予測された未来からどれくらい異常なのかを感知
-> ホテリングでの解説でも言っていたノイズ誤検知がこれでも発生してダメ

まだこのノイズ誤検知が未解決でこれからの研究で解決したい
-> 複数手法の組み合わせなどで挑戦

 因果グラフ生成

観測データから因果グラフを生成する際に仮定を置くか置かないかで手法が大きく異る。
-> 今回は仮定を置かないPCアルゴリズムで生成

関係ないメトリクスであるとエッジを切る境界値の策定が難しそう
-> 本来は原因なのに他の似た変動のメトリクスがあるためにエッジが切られることがあった

実験に対する実データが入手しづらいというのが大変そう・・・
-> データセットを動的生成するシステム作った（すげー

国内でAIOpsやってる人が少ないのでつらいとのこと

 QA

Q. AIOpsですでにあるツールを使うのはどうですか？
A. すでにあるツールについては詳細がないので知らん！使ってみた話が少ないので逆に知見がほしい。

Q. o11yと研究とのつながりがある？
A. 非常にある

Q. サーベイなど情報収集はどうやっている
A. Googleスカラーで収集。そして参考文献も辿っていく。

 感想

めちゃくちゃ期待大な研究領域！これ実現したらインシデント対応がめちゃくちゃ捗りそう。

 資料

https://speakerdeck.com/yuukit/sre-next-2022

 ZOZOTOWNのProduction Readiness Checklistと信頼性向上の取り組み

リプレイス -> 様々な技術要求が発生
-> PRCの必要性が発生

  • PR: 本番トラフィックが任せられる信頼状態
  • PRC: サービスがPRになっているかのチェックリスト

お手本となるPRCをもとにzozoで必要なチェックリストに変換していった。

 CI/CDとRelease Engineering

Lint, 単体テスト, コンテナ脆弱性スキャンや、コンテナイメージのデプロイができるかどうかの各種チェックリスト
カナリアリリースもできるかどうか。
-> https://techblog.zozo.com/entry/zozotown-microservices-alb-istio
-> 増大した作業負荷を解消するためにIstioを使ったサービスメッシュ化

 Performance Testing / Capacity Planning

podに適切なサイズが割り当てられているか？
-> エラーが出ないラインを基準にするのではなく、レイテンシに問題が出ないラインを基準とする
-> nodegroupも適切なものに都度引っ越し

Datadog Dashboardを使ったボトルネック把握
-> アラートが鳴ったらすぐ見て判断

 Failure Testing

アプリケーションデプロイ時の瞬断を生まない。
-> proveのinitialDelaySeconds, minReadySecondsを適切に設定
-> startupProveがv1.20にあるのでそちらも活用

terminationGracePeriodSecondsを適切に設定し、終了時も瞬断させない。

サイドカー（istio）の起動/終了順序に関しても注意。

回復性がある
-> AZ障害の復旧についても定義
-> 依存サービスについても障害があった場合サーキットブレーカー、早めのタイムアウト

 モニタリング

  • 障害時、動作確認できる簡易ツールを用意
  • アラートにオンコールガイドのリンク付けた
  • APMが設定され、分散トレーシングされていること
  • Sentryが仕込まれていること

 ドキュメンテーション

  • 新メンバーのためのオンボーディングガイド作成（ワイも作りたい・・・）
  • オンコールガイド作成

 感想

PRC大事。各社PRC公開してほしい（ワガママ

 QA

Q. どのくらい使われている？
A. 10~20回ほど

Q. サービスのローンチ後にドキュメントの更新はされている？
A. 大きめの変更が発生するローンチでチェックして、必要があれば更新している

Q. PRCの今後の課題は？
A. コストがかかる。カナリアリリースの徹底によってリリース頻度が上がったことによる人的リソースのコスト増。これはどうにかしたい。

 資料

https://speakerdeck.com/akitok_/improvement-the-reliability-of-zozotown-with-production-readiness-checklist

 組織にSREを実装していくまでの道のり(エウレカにおけるSREの取り組みの歴史)

2017年にSREチーム設立
-> 99.95%の可用性を目標
-> etc...

機能開発以外全部やる。（つよい

大量の狼アラートなど大量に問題があった。

まずは問題解決

  • スケーラビリティ不足の解消
  • 監視体制づくり
  • 運用コスト減

リソース余裕が生まれたので新たな取り組みの導入
-> パフォーマンス定点観測会をスタート
-> SLO改善
-> やったけど１年で休止

改善後、綻びが。

  • SREエンジニアがSPOFに。-> 属人性がめちゃくちゃ増えた
  • 何でもやった結果リソース枯渇 -> SREチームが一人になっちゃった
  • SREってなんだっけ・・・？とチーム全体のモチベダウン

SRE活動という長期戦に向けての心構えが出来てなかった。
-> チーム戦略のアップデートをしなければ！

今まではSREの探求の22.4をずっとやってた。
-> 組織としてSRE文化を浸透させていくにシフト
-> MVVの再定義

どういったSRE文化を浸透させてく？

  • SLI/SLO
  • モニタリング
  • Capacity Planning
  • オンコール
  • パフォーマンス測定/最適化

ドキュメントやチェックシートの作成/SREに興味があるエンジニアを巻き込んでいく。
リソース確保のための他チームへ権限移譲。
-> 何でもやりすぎたので適切な場所に移譲した

 QA

Q. SREアセスメントとプロダクション環境チェックシートの使い分けは？
A. システム構成のチェックはプロダクション環境チェックシート, アセスメントで改善サイクルやメトリクス確認などの所作で使い分けてる

Q. MVVのvalueはどう決めた？
A. チームで何回も話し合って決めた

Q. リソース配分が改善活動50%, 外部工数40%, Toil撲滅10%はどう決めた？
A. 自チームの関心事を見て、このくらいがベストなんじゃないか？と思い、こうなった

Q. インフラ管理はどのくらい任せてる？インフラ作成時に何使ってる？
A. 完全に任せてることではなくて、一部。terraformを使ってる。

Q. オートスケールなどは開発チームに移譲してる？
A. してません。SREで管理しています。

 資料

https://speakerdeck.com/marnie0301/eurekafalsesretimufalseshi-jian-sitekitashi-towei-lai-xiang
https://speakerdeck.com/takumiogawa/slozai-ding-yi

 SLO決定のためのArt of SLO

 SLI/SLO

信頼性を決めるのはユーザー
-> システムメトリクスではない
-> そこでSLI/SLOの出番

SLI: ユーザー体験を近似するメトリクス
SLO: サービスの健全性のための目標値

どれを指標にするかでユーザー満足度に則しているかが全然変わってくる。
-> CUJを使おう

 SLI決定に必要なCUJ

ユーザー行動の洗い出し
-> 本当にユーザーに必要なアクションを発見する
-> これがCUJ

CUJからリクエストシーケンス図を書き、コンポーネント間リクエストを可視化する
-> これが出来たらSLI

 CUJ -> SLIのプロセス

シーケンス図で何をやっているのかグルーピング

SLIの主だった指標分類

  • リクエスト/レスポンス
  • データ処理
  • ストレージ

(良いイベント/有効なイベント) * 100% = SLI

文章として出した指標の定義を明確化していく
-> プロファイルページの読み込みに成功する
-> プロファイルページ is どこ？: /profile/xxxページ
-> 成功って何を指す？: 2xx, 3xx, 4xxを返す/有効なHTLMを返す割合

 SLO決定プロセス

目標値/測定期間の両方が必要
-> 例: 過去28日で99.95%成功
-> 状況に応じてしきい値は変わり、ビジネスサイドの方とかと模索していかなければならない

とはいえしきい値をどう設定すればいい？
-> 過去データを参考に（何%の人にどれくらい早く返せてる？とか）。またお金に関する機会損失が見受けられるところは厳しく設定するなど。
-> SLOは常に見直していくことが大事

SLOからエラーバジェットが出せる。

The Art of SLOsというワークショップがこれらの流れを学習するには良い。（社内ワークショップにも良いよとのこと）
https://sre.google/resources/practices-and-processes/art-of-slos/

これは山口さんが解説されてる動画
https://www.youtube.com/watch?v=0-VeHgV2G_U

 QA

Q. SLI/SLOの種類と規模感を教えて下さい
A. １チームが管理できるSLOは3~5個。より有効なSLI/SLOを探るのがセオリー。

Q. CUJのプロセスで気をつける観点は？
A. 新規機能が入ってくるときに既存のUJに影響がないか？を振り返るのが大事

Q. SLOが実際満足されているか評価はどうしてる？
A. ユーザーが満足しているかどうかの別の指標を使う。例えば離脱率/リテンション/カスタマーセンターの問い合わせとか。

 メルカリグループにおけるSREs

2020年の登壇からの差分を発表

 Embedded SRE at Mercari

プロダクト開発チームはデプロイ/運用などを自律的に動かしていく
-> SRE, Platformチームはその支援をする

Embedded SREのミッション

  • リライアビリティの改善
  • SREのプラクティスをプロダクトチームに浸透させる

オンコールのみの対応のためのリソース要求は拒否する。
常に居続ける = Embedded SREではない。チームをローテーションする。=> ローテーションは属人性を作らせたりさせない良い仕組みじゃないかと思った。

検索基盤のEmbedded SRE
-> 一番リライアビリティの改善が求められる

今後は部門としてEmbedded SREを構築したいとか考えてるらしい。

Chaos EngineeringはChaos meshを検討中らしい。
https://twitter.com/deeeet/status/1525745700817866753

 Merpay SRE Teamが目指すもの

メルペイは高い信頼性が求められる。
とはいえチャレンジのための新機能開発も求められる。

サービスの成長を妨げる溝にはまらないためにガードレール（セキュリティ、法的要件、SLOなど）を作るのがSREのお仕事。

インフラの信頼性を上げるために、複数のクラウドベンダーを組み合わせたりしている。

開発チームのみで運用し続けていけるようにツール開発などなどやってるたり、などなど。

 QA

Q. 半年しかEmbeddedできないデメリットは？
A. オンボーディングに時間がかかって本来やりたいことが出来ないことはありうる。そういった場合に延長したことはあった。

Q. SREの支援ツールについての展望などはありますか？
A. メルペイのSLOツールの紹介 -> すでにあるものとしてSLOダッシュボードを作ってる。自動で監視項目作ったり、SLIの変化を見れるようなものの整備をしている。

Q. Embeddedの知見を共有する場や工夫はありますか？
A. 週１のSREチームでのMTGで共有している。

Q. 何を重視してEmbedded先を決めてる？
A. 定性的決める場合と定量的に決める場合がある。定量的: インシデントやアラートの量によって決める、定性的: 大きい新規リリースがあるとかで決める。

 新規ゲームのリリース(開発)前からのSRE活動

SREとは何か？の振り返り。

本番環境が無いときにSREがやれることはない？
-> そんなことはない。事前に信頼性向上の支援はできる。

新規ゲームでの課題
リリース後の大きな構成変更刷新は不可
-> 課題解決のためのセットアップリストを用意している

リストを抜粋して紹介

開発用リポジトリの使い方の検討、決定
-> モノレポにする？それとも用途ごと？

サイズの大きなファイルの扱いは？
-> 非常に大きなものを扱う場合、最悪リポジトリの作り直しも...

ログの運用方法・ポリシー
-> 理由が大事。whyに対しての解答としてのログ。
-> 時刻のフォーマットは揃えるよう徹底する

静的サイト
-> プラポリ・利用規約の検討

ティザーサイトなどはゲームあるある
-> ドメインの手配など

https://mixi-developers.mixi.co.jp/generate-terraform-code-easily-fbb151afe8f0

リリース前でもSRE手法は実践できる！

 QA

Q. 負荷に対しての対策はありますか？
A. 過去の事例が色々あるので、そちら参照してね。

Q. チェックリストはリリース前のどのタイミングでレビューしていますか？
A. 随時開発中の良きタイミングで行っている。

Q. どういう風にSREメンバーが入っていく？
A. PJが立ち上がって参加することもあるし、既にあるものに途中か入ることもある。新規ジョインが最近は多い。

 その他

  • SRE NEXT初めて参加したけどめちゃ体験が良かった！
  • 演出がかっこよい（セッション前動画とか）
  • zoom events初めて使ったけど自分が聞きたいトラックのタイムテーブル作れたりして体験が良い