生涯未熟

生涯未熟

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

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スタンプの実例紹介:小さく始める障害検知・対応・振り返りの改善プラクティス

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

ヒロイズムなチームについて。
-> インシデントに対してエキスパートがすべてこなす
-> エキスパートのみが経験値を得て、皆がエキスパートへ頼り経験値を得る機会が0になる
-> 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

3つのチーム

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

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

 QA

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

Q. Shopifyの規模でGame dayをどうやっている?
A. サービス単位でやっているので1つの規模としてはでかくない(だいたい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改善
-> やったけど1年で休止

改善後、綻びが。

  • 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. 1チームが管理できる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. 週1の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初めて使ったけど自分が聞きたいトラックのタイムテーブル作れたりして体験が良い

ポーカーやり始めて2ヶ月でポーカーチェイスの最高ランク帯到達した

ひょんなことから世界のヨコサワさんの動画を観て、「そういやポーカーやりたい欲求あったな〜」って思い出したので3月からポーカーを開始。

※エンタメに富んでて面白い

ルールや基本的なことを覚えてからエムホールデムから始めたが、演出がくどいのと役成立確率の表示が気に食わなくて他にポーカーゲーム無いかな〜と探していたところ、ブラウザでもできるポーカーチェイスを発見し、3月末からガツガツとプレイしていきました。

で、今日ようやく最高ランク帯のダイヤモンドに到達しました。

どういうことを考えていたか?

まずは基本的なルールを覚えてから慣らし運転。そこからこちらのスターティングハンド表とハンドレンジの記事眺めたりとか

raq-hiphop.com

ヨコサワさんのポーカー解説チャンネルの動画見たりして、ポジションの重要性を学んだりしました。

基礎的なことは理解できたので、そこからはランク戦をバンバンこなしつつ「何故そのアクションをしたのか?」をキチンと言語化し、出来ない場合には何が分からなかったのか?を突き詰めるようにしました。(全部が全部言語化出来るわけじゃなく「それ運ゲーじゃん!」って思考を投げ棄てたりもしてます:-)

それ以外でなんとなく心がけるようにしてたのは以下です。

  • 人読みされないようにする
  • カモられてるのを早めに察する、バレないようにカモる
  • ルースプレイヤーが多い時はタイトに、タイトプレイヤーが多い時はルースに
  • 相手のVPIPをアクションの判断の一つにする
  • スタックの価値が希釈化する前に多く勝負をする
  • なんだかんだで最後は直感

人読みされないようにする

個人的にポーカーは人読みを煮詰めたゲームだなーと思っているので、人読みはかなり重要なファクターだと考えています。
大別するとルース・タイト・アグレ・パッシブの4つのスタイル組み合わせでプレイスタイルを分けれますが、場のプレイヤーをそれぞれのプレイスタイルで当てはめてアクションの参考にするのは重要です。

で、それを踏まえて自分が一番やられて困るのは大別したプレイスタイルから大きくハズレた行動をされることでした。
めちゃくちゃ固く打ってたプレイヤーがとんでもないブラフしてたり、逆にルースアグレな人に乗ったら相手のハンドがナッツだったりとか・・・
ボードゲームの基本だと思いますが、他人からされて嫌なことは戦術的に有効なので、自分も読まれてるな〜と思ったら全く違う行動で相手を驚かせてチップをぶん獲っていきましょう。

カモられてるのを早めに察する、バレないようにカモる

ポーカーはチップをカモったりカモられたりしてスタックを増減させていきますが、当たり前の話でカモられないようにしてカモりましょうというお話。
中でもカモられないようにするのが一番大事かなと。自分よりももっと経験値の高い方がその辺りの記事を色々と書かれていますが、その中でもリンプはしないってのは絶対に守っていました。あとは熱くなって相手のレイズに乗らないってのはありますかね、熱くなるとロクなことにならないので時間いっぱい使って深呼吸&思考の整理してからアクションしましょう。

逆にバレないようにカモるってのは自分がナッツハンドの時にそう見せないようにアクションすることです。よくあるのが時間を使って悩んでるフリするとかですかね。自分はリンプするとか追い込まれた状態で泣く泣くオールインしたって感じに見せるとかをやってました。
弱く見せるのはコミュニティカードの出目によってもやり方が変わるので、本当に難しいなとまだまだ研鑽中です・・・(こういうのを"アドバタイズ"と呼ぶのをさっき知りました :-)

ルースプレイヤーが多い時はタイトに、タイトプレイヤーが多い時はルースに

これは書いてある通りで、場に参加するプレイヤーのプレイスタイルの多さで戦略を変えています。
ルースプレイヤーが多いときに一番嫌なのが「弱い手で勝ちまくられること」と「たまたま入った強い手で勝たれること」です。この2つの封じ手としては単純に強いカードでのみ勝負するタイトに徹することです。弱い手には勿論勝てますし、強い手でも勝負にはなります。こういう時は稼ぎ場ですので、強い手でどんどんバリューベットしていきましょう。

次に、タイトプレイヤーが多い時はブラフベットで相手を落としやすいです。ルースプレイヤーが多い時と違って、単純にどんどんブラフをかましていきましょうというよりはヘッズアップの際にワンペアのみとかでも強気にベットしていきましょうくらいの感覚です。

相手のVPIPをアクションの判断の一つにする

相手に雰囲気の違うアクションをされた時に、よくVPIPをチェックしてアクションの判断材料にしています。
なんとなくですが、

  • 60%以上: ブラフの可能性が非常に高い
  • 50%以上: ブラフの可能性が高い
  • 40%以上: ブラフの可能性が少し高い
  • 35%以上: もしかしたらブラフ?くらいの可能性
  • 30%付近: ほぼほぼブラフをしない

といった感じで見ていました。
一つの参考程度なので必ずしも当てはまらないことがあるかもですが、何も情報がないよりかはマシかなと。

スタックの価値が希釈化する前に多く勝負をする

ランク戦では3分毎にブラインドレベルが上がります。つまり1BBの価値がゲームが進むにつれて希釈化されていくことになります。何もしなくてもスタックサイズは下がっていくので、序盤に多く勝負することを心がけていました。弱めのスーコネなど勝ち目が少なからずありそうなものでも、ベットしていくようにすることで割と勝率が上がっていきました。
めちゃくちゃ弱い手でもガンガンいけとは言いませんが、勝ち目がある場合は勇気を出していきましょう。

なんだかんだで最後は直感

結局はこれに行き着きます。どれだけ考えても意図が読めんことも多々あるので、際どい判断が求められる際は直感に委ねます。 第六感を磨きましょう:-)

ポーカーたのしい

ずっとプレイしながらポーカーたのしいなぁとモチベが上がったり下がったりしながらもずっと思ってました。麻雀よりも読みが求められるゲームで、個人的にはポーカーの方が向いてました。
ライブポーカーや実際にお金を賭けてやるとまた違った体験が得られそうなので、気が向いたらやってみたいですね。暫くは飽きなさそうなので、もっと腕を磨いていきます💪

エンジニアはもっと図を書こう

たまには軽い話題をば。

自分の中で信頼できるエンジニアかどうか?を見極めるひとつの指標で「込み入った議論の時に図を書くかどうか」というのがあります。
今までの経験上、図を書く派のエンジニアは割と良い感じの人が多かったので採用している指標なのですが、何故これが機能しているかというのを改めて考えてみた。

  • 他者の認知負荷を理解している
  • コンテクストを合わせることにコストをかけられる意識がある
  • 自分の思考の整理するツールとして図を扱えている

ザッと挙げましたが、この3つが機能している要因なのかなという気がしています.

他者の認知負荷を理解している

あれやこれやエンジニア間で技術議論している中で、「Aさんはこの領域に詳しいけどBさんはこの領域にはほどほど詳しいくらいだな」という個々のレベル差に応じて認知の負荷がかかります。ただでさえ議論していると結構なスピードで話が展開されていくので、認知負荷が更に加速してついていけなくなる人も多くなることでしょう。
そういった人を話のラインに合わせてあげるために一回議論を止め、図を書いて「こういうイメージで話合っていますかね?」とワーキングメモリのリセットがかけられる人はチームのために動けてるなと信頼がおけます。

コンテクストを合わせることにコストをかけられる意識がある

先述と似たような話なのですが、きちんとコンテクストを揃えることにコストを払える人は良いエンジニアと考えています。たまに自分の知識レベルでガーッと喋って満足しちゃう人もいますが、そういった人は正直あまり好みません。
ある主題に関して全員の認識を合わせることが、将来的なチームの協調行動の強化に繋がるのでそういったチームの未来という絵図を描いて行動できるエンジニアは良いですね。

自分の思考の整理するツールとして図を扱えている

これは完全に主観なのですが、パッと頭の中で考えてることを整理された状態で図に書き起こせる人は能力が高い印象があります。普段からちゃんと思考が論理的に頭の中で組み立てられているので、図に起こすのもスッと出来るんだろうなーという気はしています。

図 > 文章

文章だけよりも図があることで理解度の向上の助けになっているということが感覚値では持っているものの、なんらかのアカデミックな論拠が無いかなと調べていたらこんなの見つけました。

jiotower.org

“マルチメディアの原則”として知られている原則は、”人々は言葉だけからよりも言葉や絵からより深く学ぶ”(p.47)と述べている。

あとはJohn Swellerさんの認知負荷に関する文章とか読んでいけば、もしかしたら似たようなことが書いてあるかも。(未調査)

薄ぼんやり考えてることをたまにはつらつらと書いてみるのは良いですね。また何か良いトピックがあったら書いてみます。

GitHub Projects(beta)からバーンダウンチャートを生成する君を作った

所属しているチームで本格的にスクラムを回していくにあたって、タスク管理しているGitHub Projectsでバーンダウンチャートを生成出来ないか?という話になったのでサクッと作ってみた。

前提

目的としてGitHub Projects(beta)にあるスプリントバックログにプランニングポーカーでポイント付けをしたタスクを置き、これをデイリースクラムで理想的な進捗で終わらせているのか?を可視化したかった。
初めはGitHub Projectsにあるチャートで実現できないか?と試してみたが、表現力に幅がなくtodo, in progress, doneなどのステータス毎のタスク数による折れ線グラフなどを作ることは出来るが、ポイントを考慮したチャートは作成できなかった。

そのため、GitHub APIを叩いてバーンダウンチャートを生成するのが良さそうという話になり、調査&作成することとなった。

要件として、 - GitHub Projects上にあるタスクのポイントを使って、バーンダウンチャートを生成する - バーンダウンチャートの表示先は問わない - 日毎の進捗データをどこかに保存する - 定期実行だけでなく手動実行でも最新の進捗データを反映する - なるべく運用の手間はかけない(データ反映に複雑な手順を踏まない)

と定めて開発をスタートさせました。

実装

最終的に出来たのはこんな感じ。

f:id:syossan:20220327125014p:plain

これだけ見たらただのスプレッドシートにあるグラフですが、裏では色々やっているので解説していきます。

技術概要図

f:id:syossan:20220327130953p:plain

ザックリこんな感じで、先程の要件と照らし合わせるとこうなりました。

  • GitHub Projects上にあるタスクのポイントを使って、バーンダウンチャートを生成する
  • バーンダウンチャートの表示先は問わない
  • 日毎の進捗データをどこかに保存する
  • 定期実行だけでなく手動実行でも最新の進捗データを反映する
    • 定期実行はCloud Scheduler、手動実行はGASを通してCloud Functionsを実行
  • なるべく運用の手間はかけない(データ反映に複雑な手順を踏まない)
    • 普段はノーオペでグラフ見るだけ、直近でタスクを動かした時(in progress -> doneの移動など)は最新データ取るためボタンを2回押すだけ

なんとか良い形で要件をまとめることが出来ました(なるべく手を動かさないで)。
では一つずつ詳細に見ていきましょう。

GitHub API v4でGitHub Projectsからデータ取得

最初の取っ掛かりとしてCloud FunctionsからGitHub APIを通して、GitHub Projectsのタスク一覧を取得してきました。
GraphQLを用いたv4でデータを取ってこようと思い立ち、Goのgithubv4を使って取ってくることに。

github.com

サンプルコードとしてはこのように、1Queryで100件までのタスクしか取れてこないので、PageInfoにある情報を使って全てのタスクを取ってくるようにしてあります。

あと、説明が必要なのはGitHub ProjectのノードIDについてでしょうか。これはProjectごとに設定されているIDで取得方法は以下公式ドキュメントを参照。

docs.github.com

で、取得してきたタスクの情報を元に全タスクの総計ポイントと残タスクの総計ポイントを集計。集計したデータをBigQueryに入れるように実装しました。この辺りは特段説明のいる実装をしていないので解説は割愛。

Cloud SchedulerでCloud Functionsを定期実行

これも特に説明することはなし。一点、Cloud FunctionsをSchedulerからもGASからも実行させるために、HTTPトリガーに設定しておくこと。

GASでCloud Functionsを実行

こちらの記事を参考に実装。

qiita.com

記事通りに実装していけば詰まることもなく実装出来るはず。

スプレッドシートとBigQueryを連携

スプレッドシートはBigQueryと連携することが出来、データを引っ張ってくることでスプレッドシート上で利用することが出来ます。今回だと引っ張った日毎データをグラフに起こすところで使用しました。連携の仕方は公式ドキュメントを参照。

support.google.com

そして、連携したBigQueryではクエリを元にスプレッドシート上に展開してくれるので、今回では以下のようなクエリを実行しています。

このクエリでは単純に日毎データを引っ張ってくるのではなく、重複レコードがあった場合にtimestampが最新のレコードのみを利用するようにしてあります。こうしないと、BigQueryへinsertする際に「既に実行日のレコードがあった場合にupdate」とか「既に実行日のレコードがあった場合にdeleteしてからinsert」とかやらなきゃいけないので、面倒だなと思い重複レコードを許容しています。

そして、あとは日毎データを元にバーンダウンチャートを起こします。

f:id:syossan:20220327141656p:plain

抽出して貼り付けたデータは表示のフィルタリングが出来、それを使って「○日〜○日のデータのみ表示」とすれば柔軟にスプリントの変化に対応することが出来ます。

ちょっと詰まったところといえば、理想線をどうやって表現するか悩んだところです。一番簡単なのは総計ポイントの系列に対してトレンドラインを引く手法でした。トレンドラインを「総計ポイント -> 0」へ遷移する系列へ適用してあげればOKです。

また、BigQueryからデータを引っ張る際には連携したシートか、抽出して貼り付けたセル上で更新ボタンを押下しないと更新されないので、連携機能内にある定期更新を設定しておくとよいと思います。

スプレッドシートからGASの実行

最後にスプレッドシートからGASを実行します。これはボタンから実行するようにしてあり、やり方は以下を参照。

www.acrovision.jp

運用

これで普段はCloud SchedulerとBigQuery連携したデータとの定期更新、デイリースクラム時などで最新のデータを見たい時にはCloud Functionsを実行するボタンの押下とBigQuery連携したデータの手動更新を行えば使える簡単なシステムになりました。

まとめ

久々にGoを書いて実装してみましたが、やっぱりGoは書くの楽しいですね。
どうやって運用を簡単にするか?が結構右往左往悩みましたが、これが一番簡単だと思います。

GCPのIAP周りの隠れ仕様

dev, staging環境のアクセスを社内の人間のみに制限したいな〜って時にGCPのIAPを使っているのですが、そんなIAPの隠れ仕様を見つけたのでメモ✍

どんな仕様?

IAPはOAuth2 Client IDを必要とし、IAPを有効化することによってOAuth2 Client IDが増えていきます。 その様子は"APIとサービス"の"認証情報"を見ると分かるのですが、実はこのOAuth2 Client IDは36個までしか登録出来ません

stackoverflow.com

こちらのスタックオーバーフローを読むと色々と書いてありますが、公式なやり取りだと以下を読むといいかもしれません。

issuetracker.google.com

私もこの質問者と同じくIAPを新規作成する際に36個制限を越えてしまい、エラーとなってしまいました。
36個を越えて登録したい場合はGoogleに問い合わせてくれと回答している方もいますが、公式なやり取りを読むと「制限があり、上限を上げる予定はない」って書いてありますね🤔

正直、この辺りに関する情報が全く見つからず公式ドキュメントを漁っても見つかりませんでした・・・
現状では必要のないIDについては削除していくしかないようです、というお話でした。