hbstudy #74 SRE大全

7/25.Tue

• SREを翻訳した玉川さんの話し
  • Sky株式会社
  • 翻訳多い
  • ヘルシープログラマの本
  • SREでやっているわけではない
• SRE本について
  • The SRE Book としてアメリカで人気
  • メルカリ,スマートニュース,サイボウズでもSREチームが作られている
  • SREチームを作る時、カタカナよりのほうが話しやすい。だからカタカナよりの本になっている。
  • 英語版サブタイトル「How Google runs production systems」
  • 日本語版サブタイトル「Googleの信頼性を支えるエンジニアリングチーム」
  • 決して魔法のような技術の本ではなくて、組織論に近い
  • 技術論よりも組織論
  • 組織としての考え方が果たしている役割が大きい
  • フリーランスやスタートアップの規模でも学べることがある
  • 34章あるうち、半分近くは組織論に近い
• Googleの翻訳
  • Google Docsのヘビーな活用
  • 地道な自動化結構やってる
  • office系ツールの活用能力高い
  • DropboxでPDFの共有して校正した
  • Theyが単数形として使われているのが増えてる
  • Gender neutralな表現
  • he,sheは名前に変えている
  • 英語にすると話しが通じない場合があるからカタカナにしている
  • カタカナにすると共通ワードとして話しやすい
  • 決まったルールがあるわけではないが、一冊の本の中では統一ルールを持たせている
  • エラー予算,エラーバジェットにするかなど
  • ヘルシープログラマーは良いものとして読みやすいようにした
• SREという職種/チーム
  • 基本的には運用サイド(Ops)の職種。DevOpsのOps側
  • これまでと違うのはOpsがプログラミングができる
  • 基準の8~9割が必要
  • デベロッパーとしても出来る
  • SREというポジションはスター性が高い
  • 運用だけをやっている人とは違う
  • 8~9割で、且つインフラよりの技術ももっている
  • 本に明確に書かれているわけではないが、全社的な考えを組み込むような横断的なチーム
  • 仕事は大きくわけて運用業務（オンコール）と「改善」のためのエンジニアリング
• SREの原則
  • 信頼性にフォーカス
  • サービスをうけもっているSREチームは、サービス拡大しても人数は増えてはいけない
  • 手動化→自動化→自律化
  • スケールさせていく
  • トイル
  • 英雄的な献身に頼るのではなく、組織として仕組み作りする
• 10月にGoogleのSREイベントがあるかも
• 速度と信頼性
  • 速度=パフォーマンスの話しではない,新しい機能やサービスを投入するペースのこと
  • SLO→組織の中で定義
  • 開発者は速度がモチベーションになりがち,運用者は信頼性を重視する傾向がある
  • 開発者と運用者の緊張関係
  • 計測されたデータに基づく業務判断
  • エラーバジェット
  • “1 – SLO”
  • 成功したリクエスト数/リクエスト数
  • 投げられたリクエストに対して成功しなかった数
  • 四半期ごとにカウント
  • エラーバジェットがなくなったとき、リセットできるまで新機能のリリースができない
  • 100%は目指さない
  • 99.99%と99.999%の違いはユーザーには区別が付かない
  • 50%ルール
  • 50%を越えたら開発者もサポートに入らないといけない
  • 開発者と運用者の緊張関係をなくす
  • 計測と改善の仕組み作り
  • 必要なメトリクスを得るための仕組みをインフラに作り込む
  • ツールを作って改善しているに近い内容だった（らしい）
  • 徹底した自動化志向
  • メリットは複利
  • 手動（トイル）→自動化→自律化
  • 手作業で繰り返し行われることを自動化
  • 採用、育成の話し
  • 需要に対して供給不足
  • ライブラリをSREが提供して、それをもとにサービスを開発すると必要なメトリクスを取れるようになる
  • SREはオンコール対応になることはキャリアの一つのマイルストーン
  • 教育システムをきちんと教育する
  • ドキュメント→ポストモーテム→シャドウ(オンコールの弟子的な）→オンコール
  • 障害対応とトレーニング
  • 「たまにしかやらないことは身につかない」ことを受け入れる
  • 障害対応でやるような手順を日常業務に組み込んでいる
  • まとめ
  • 自動化によってスケーラビリティの向上、トイルの僕メル、そしてさらなる自動化のための時間をつくること
  • ソフトウェア開発によって運用を改善していくこと
  • データの定義、データを計測する仕組みつく
  • チームが同じ方向をむけるように

• その他
  • 自動化の話し https://gist.github.com/voluntas/08671d717290a6f63cddd95052a33a86
  • Googleのコンテナの計測ツールが統一的な仕組みが導入されている
  • C++,go,python,あとなんか
  • 評価→与えたインパクトも大きい