豊洲で行われたSREカンファレンスの参加レポ。
自分が参加したところを書いていく。行けなかったところについては他の参加レポを待つ！
- ヨガプログラム
- 基調講演: 分散アプリケーションの信頼性観測技術に関する研究
- 40000 コンテナを動かす SRE チームに至るまでの道
- パフォーマンスを最大化するための SRE のオンボーディング事例
- delyにおける安定性とアジリティ両立に向けたアプローチ
- SLO Review
- SREがセキュアなWebシステムを構築、維持するためにやれることはなにか
- サイト信頼性エンジニアリングの原則
- 基調講演: Webサービスを1日10回デプロイするための取り組み
- パネルディスカッション
- 感想
ヨガプログラム
ヨガしました。
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
ヨガの呼吸全集中です #srenext
身体が硬すぎて先生が言ってたこと３割位できてなかった気がする…。普段とは違う動きができた。
基調講演: 分散アプリケーションの信頼性観測技術に関する研究
- SREが何であるか？
- 講演者が取り組んできたSREの各研究を1つのストーリーに統合
サイト信頼性を制御するための工学
自動化の皮肉
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
（1983年）
・自動化でトイルを低減できる
・自動化するほど認知負荷が高まる
・負荷に耐えられるように高度な訓練が必要となる
作業負荷は減るが認知負荷が高まった。
自動化ですべて解決しない。
なるー
#srenext
皮肉へのアプローチ
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
・失敗を許容する前提で運用を設計する
・信頼性を向上させるだけでなく、短期的には低下させる選択肢を持つ
→低下させるにしても基準は必要。リスクを制御下に置くことで変更速度を最大化する
#srenext
「いかに失敗のリスクを小さくできるか」
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
・リスクの事前予測
・リスクの事後最小化
恐怖を減らし変更速度が高まる→信頼性も高まる
#srenext
クラウドゲーミングのネットワーク遅延。100msのうち80mを占める #srenext
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
NewSQL😇 #srenext
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
[https://twitter.com/inductor/status/1220918386806276096?s=20:embed]
40000 コンテナを動かす SRE チームに至るまでの道
- PaaSチーム
- SREチームマネジメント
基本的なことを丁寧にやっている印象。 大規模な組織でできていることがすごい（こなみかん）
「40000コンテナ」すごいー #srenext
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
ヤフーのSRE
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
Private PaaS、エンジニア3200人が使う
本番16クラスタ、40000コンテナ
ヒエッ。規模やべー
#srenext
「PaaSを通じて社内利用者の開発効率を圧倒的に改善する」
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
3200人もいたらそれだけで必要な存在すね
#srenextA
PaaS運用の課題
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
・安定化にかけるコストが不透明
→利用者に聞く。指標と利用者の声をもとに優先度を交渉
・アラートからサービス影響がわからない
→影響の可視化。アラートが細かすぎて利用者の影響がわからない。社内SLA, SLO(アクセス可能、デプロイ可能などをSLIに)
#srenextA
SLOを一覧化したダッシュボード。
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
個別のしきい値を持っていて正常異常を色で判別できる。
パット見てすぐわかる。が偉大なのがわかるな
#srenextA
・新規メンバーの教育コスト
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
→アラート対応の工夫。メンバーが最も成長するのはアラート対応
対応者を固定（2名体制週替り）
あえて障害に集中させる工夫
担当者でない人は開発に集中できる
大規模障害はふりかえり（ポストモーテム）
ベテランメンバーは何を考えて対応しているか
#srenextA
「徐々に責任範囲を広げていく」「失敗を許容する」「優先度判断軸にSLO」
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
ScrumならではのふりかえりとTRYを細かいサイクルも入れる。
すべては利用者に最も価値あるものを提供するため
#srenextA
パフォーマンスを最大化するための SRE のオンボーディング事例
- これまでのオンボーディングの課題
オンボーディングに特化した取り組みに関する話。 オンボーダーをどう評価するのかが課題。
「パフォーマンスを最大化するための SRE のオンボーディング事例」
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
・SRE中途採用者が対象
新しいメンバーができるだけ早く活躍できる仕組み
そのメンバーを含めてチーム全体のパフォーマンスを最大化すること
#srenextA
オンボーディングの目的＝1人前になる
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
として「オンコールを一人で担当できる」こととしている。
オンコール担当はメトリクスやログを見て問題の調査ができるかーだけじゃなくてサービス機能まで含めて理解しているかってことなんすね。
技術力は前提で、そこにサービス理解もしてもらう
#srenextA
技術的知識の習得だけが対象になると、コミュニケーションが生まれにくいという課題。
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
Kubernetes環境つくろうねーとかだとひとりでもくもくしているだけになってしまうと。
組織やサービスのキャッチアップがされてない問題
#srenextA
ペアプロならぬ、ペアオペレーション。
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
オンコール担当とメンターでやる。
Developerとコミュニケーションができるし、技術とサービス知識も学べる。
おお、いいすね。でも新メンバーがいないので試せない
#srenextA
割とどの組織もオンコール当番があるんですねー。
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
うちはないので基本全部やるみたいな感じになってるけど、、人数がいないのでこればかりはしゃーないな
#srenexta
オンコール対応のシャドウイング。いわゆる見学。学習効果高いわかる #srenextA
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
オンボーダーの評価は難しい。定量的にならない。
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
考えられるのは、かかった日数や満足度、360度評価。
Traning SRE本を参考にするなど
#srenextA
delyにおける安定性とアジリティ両立に向けたアプローチ
- SREの存在意義
- プロダクト開発の速度を安全に高めるためにすべきこと
- delyにおける具体的なアプローチ
SREがSREとしてすべきことや、delyが開発してきた歴史的経緯からくる課題アプローチまでがわかる話。
SREが登場した背景
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
・クラウドが普及する前、サービス運用と開発業務のスキルセットが別だった
・その結果運用組織にソフトウェアエンジニアのスキルがないため運用が手作業に
・組織が違うので開発と運用の目標も違う。結果、安定させたい運用とリリースをたくさんしたい開発で対立する
#srenextC
SREは基準を設けて、安定と開発速度のバランスを取った。
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
なおSREがいるからといって対立構造が解消されるわけではない。#srenextC
対立構造を解消するため、SLOを設定し、バランスを取る。
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
SLOからエラーバジェットが算出。
それをもとにリリース判定を客観的に実施できる
SREは”信頼性を高めるためだけ”ではなく”プロダクト開発の速度を安全に高める”ためにもいる
なるほでょ
#srenextC
「常に複雑さを取り除きシンプルにしておけ」
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
#srenextC
SLO Review
- SLOについて
- Quipperの場合
SLOとSLIをどうやって決めていったか。レビューしていたかがわかる話。個人的に一番聞きたかった＋わかりやすさNo.1だった。 SLOの設定や運用を知りたい人は必見。
楽しそうに話すなあ😃 #srenextC
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
SLO/SLI理解してるけど実際に設定仕方がわからない問題。
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
→Github Issueに愚直に記録
→DatadogのダッシュボードでSLOだしとく
→1週間で計測。３ナインを基準
→SLOを定期的にレビューすること
#srenextC
ちょっとずつSLIを足す。一気に完成を目指さなくていいんだ #srenextC
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
「503ダメ」にすると信頼性を守っているのに真逆に見えることがあるという話あ〜＾って感じ #srenextC
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
503 から 429 に変更してSLOのノイズを減らすの納得#srenextc
— Daisuke Komatsu (@tigerroll54s) 2020年1月25日
SREがセキュアなWebシステムを構築、維持するためにやれることはなにか
- セキュリティへの取組事例
SREチームが担う範囲の大きさに驚き。AWSに関連する具体的な話もあって為になる。
セキュリティ強化とSLO/SLIに取り組んでいる最中なので期待 #srenextA
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
セキュリティ、後手にまわりがち #srenextA
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
コミュニケーション原則
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
・他チームとの間に壁を作らない
・押し付け合わない
・冷静に議論する
・ビジネスにとって優先すべきか話す
#srenextA
ヒアリング
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
・どんなライブラリ使ってるか
・パスワード管理
・ログにユーザを特定する情報はマスクしてるか
・アプリ側に強制アップデートする機能があるか
#srenextA
有事の際の指揮系統、チェックリスト、プレイブック、プロトコルは重要。#srenext #srenextA
— kohbis (@kohbis) 2020年1月25日
ポストモーテムにリアクション付けるのいいな。イイネボタンが使えるツールで管理したい。 #srenextA
— てん (@tenn_25) 2020年1月25日
認定試験で見るやつだhttps://t.co/GfmBWUDfvi#srenext #srenexta
— あいさか (@mist_dev) 2020年1月25日
session managerを使えhttps://t.co/bSoXdCSmBA
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
#srenextA
サイト信頼性エンジニアリングの原則
- SREの原則
GoogleのDeveloper Advocateによる発表。基礎の基礎であるSREの考え方。これを理解せずしてSREは名乗れない。
基礎に立ち返って「サイト信頼性エンジニアリングの原則」 #srenextA srenextA
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
柔軟性より一貫性のほうが価値があることがよくある。
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
例外はコストが高くつく
複雑さは減らす。 #srenextA
SLO違反がないのにアラートを飛ばすのは罪深い #srenextA
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
SLO99.9%を達成できてるなら何してもいいぞっていう基準。AWSは４ナインてことを参考にして決め
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
#srenextA
「誰がどうしたので注意する」という書き方はNG
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
人間がどうでもいいし、注意するというアクションも人間がやることなのでNG
障害再発をポジティブに防ぐ。スクリプトで安全化するとか#srenextA
エラーバジェットとは定めたSLOで許容される時間のこと
— hap (@boy_hap) 2020年1月25日
以下のことを行う時間
メンテナンス・デプロイ
耐障害性テスト
よりシンプルなアーキテクチャにする#srenext #srenextA
基調講演: Webサービスを1日10回デプロイするための取り組み
- 1日に10回デプロイするための工夫
circleciの数とお金で殴ると確かに速くなる #srenext
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
「circleciのコンテナはusにあるのでテストするたびに転送時間がかかるので、テスト用のコンテナは同じリージョンに置くだけで速くなる」
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
やっぱそっちにおいた方がいいのかー😇
#srenext
カヤックさんと技術スタックが似通っててわかりみが出てる
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
・circleci
・rundeck
---
だれでもデプロイできる（コード書いたやつがする）ようにして、誰がいつデプロイしたのかもわかる工夫。
プルリクを取得して可視化してるのすごい
#srenext
Slackbotが「昼だけどデプロイしていいの？」って忠告してくれる仕組み。
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
いいすな #srenext
組長、CIとかデプロイとかの10年間の歴史を話してくれてる。10年間運用したシステムを過去の経緯を含めて話してくれるのって、背景がわかるからその技術の重要性がわかっていいんだよね。on boarding とかでも昔語りメソッド使うといい。 #srenext
— Yukitaka Ohmura (@yktko) 2020年1月25日
#srenext rundeckでデプロイ。コマンドを実行するだけ。色々できるが、それだけにしないと危険デプロイのログは、songmu/ghch で引っ張る。それをgoogleカレンダーとか、mackerelのグラフアノテーションに設定。勉強になる
— ken\d (@ken5scal) 2020年1月25日
デプロイに含まれる PR を抽出して Mackerel とカレンダーに自動で記録 #SRENEXT #SRENEXTA
— あえとす⛩ 2/23 秋葉原ボドゲ会 (@aetos382) 2020年1月25日
まとめ
— nago3 (@mrnago3) 2020年1月25日
・全部を早くしましょう
・安全に行う仕組みを作りましょう
面白かった、ありがとうございましたー
#srenext pic.twitter.com/iK5mqEj8dy
パネルディスカッション
- 超豪華パネラーによるディスカッション
これだけのコンテンツを格安の参加費で聴けて申し訳なくなってきた #srenext
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
「Rettyにたまたま遊びに行って俺がいなかったら壊れてなくなってた」
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
エピソードつよすぎて草#srenext
Retty樽石さん「SLIやSLOは決めていましたが、SREという名前の役職はなかった」。これはその通りでキーワードの定義に合う役職があるのでなく、組織に必要なタスクをやる役職がある。アジャイルの定義を考えることに意味がないのと似た話。 #srenext
— Yukitaka Ohmura (@yktko) 2020年1月25日
SREて名乗っていいのか不安めちゃわかるううううわかるううう。
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
「SRE本に書いてあること全部できてなくても、ちょっとずつやっていけばいいんだよ」というぐう聖コメント
#srenext
#srenext そうですよね…そうですよね… https://t.co/UbllQ5foMF
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
そう考えると、スキルセット云々とかじゃなくて、新機能開発なのか信頼性向上なのかという、何をターゲットにしてるかのマインドみたいなのでSREなのかどうかなのか決まるともいえるんじゃないかしら #srenext
— doublemarket (@dblmkt) 2020年1月25日
Q. これからSREチーム作りたいんだけど何から始めたらいい？
— あいさか (@mist_dev) 2020年1月25日
A. 必要なスキル設定は組織課題によるのでなんとも言えない。一般的なwebの知識、データを集めて分析できる力は共通項としてあげられるかも。#srenext
Q. SREの組織的な期待値、成果って何？
— あいさか (@mist_dev) 2020年1月25日
A. SREに期待されるのは生産性と信頼性のバランスをとること。サービスの特性、組織のフェーズによって割合も変化していく。その辺りを継続して提供していくこと。#srenext
Q. SRE本てどんな人が読んだらいい？
— あいさか (@mist_dev) 2020年1月25日
A. 今まで運用をやっていて、単調でおもしろくないなーと思っていた人たちが一歩ポジティブに踏み出すためのきっかけとして読んでもらうの良さそう。#srenext
Q. SREの評価ってどうしてる？
— あいさか (@mist_dev) 2020年1月25日
A. SREチームのOKRを定義する。SLO/SLAなどを定義する。その上でどんな取り組みをしているかをみている。#srenext
Q. SREと呼ばれる人はこの先なにに取り組んでいきますか？SRE無くなる時は決ますか？
— タロー@綺羅星十字団 (@dohq) 2020年1月25日
A. 適材適所(オンプレ/クラウド)を使い分けていくかも。
マネージドサービスのカバー範囲が増えてきてるので、専門職的な人はいらないからとなると思う。
#srenext
やっぱり基礎的なデータ構造、WEBについての知識、統計あたりは、ガッツリ勉強しないといけないな
— ogady (@gadyma) 2020年1月25日
みんな口を揃えていうなら間違いない#srenext
Google在籍12年、トータルで書いた行はマイナス10万行=シンプルにすること、捨てることをやれた結果#srenext
— Daichi Harada (@kai_ten_sushi) 2020年1月25日
SRE Workbook訳本期待！！！！ #srenext
— Shinya Tsunematsu (@tnmt) 2020年1月25日
感想
2020年1月から本格的にSREチームが組織に成立したのでめちゃくちゃためになった。
2019年はKubernetesに移行したものの、システムの信頼性を担保する取り組みは今の所なかった（IaCや最低限のモニタリング、CI/CDは実装されている）。
SLOを設定して客観的に計測したり、それをもとにシステムの信頼性向上を図っていくところでもあった。
このSRE NEXTの発表はどのセッションもハイレベルで大変勉強になった。
また、「自分が得た知識と方針は概ね間違っていない方向で進められていた」という自信にもつながった。
ピンポイントなカンファレンスに参加したのは初めてだったけれどとてもおもしろかった。
スタッフのみなさまに感謝します。お疲れさまでした！
初めて自分にとってピンポイントなカンファレンスなんだけど、自分の職種のカンファレンスがこんなに面白いものだって知った。
— VTRyo⚡️技術書典8【Day1-お13】 (@3s_hv) 2020年1月25日
ルッビカイギとかの参加者の気持ちがわかった #srenext
