以下の勉強会に参加してきました。
こちらがその本 ( 2017/8/19 発売
SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム
感想
SRE の概要や重要なポイントを解説して頂き、本を買わなくてもいいと思うものでは無く、本をより解釈できるためのガイドとなっていた印象をうけました。何しろいいボリュームですし、今回のような前説を受けてから読むことができるのはありがたいことです。
しかも、単純に紹介で終わっておらず、Googleの内情や、翻訳ならではの苦労話しも聞けて、非常に面白かったです (2h あっという間だった)。
印象に残ったのは、Google といえど、すごい人が魔法のようにシステムを構築/運用しているのではなく、地味な対応の積み重ねの話が出てくると聞いた時でした。Google 程のサービスでも、システムの運用は特別なものではなく、我々もやっていくしかないのだなと前向きなります。この本はそういったノウハウや考え方(原則)が詰まっているものと思いますので、参考にして自分たちのサービスに還元できる何かがあると期待したいです。
以下は今回の勉強会の書き起こしです。夢中でメモしていたら結構たまってしまった。
自身で解釈して表現をサマったところや、たまに、個人の感想(便利。とか)が入ってますので勉強会内容の正確な書き起こしではありませんのでご承知くださいませ :bow:
SRE hbstudy#74
諸説明
- 司会が今回から持ち回りになった
- 会場説明とか
- インフラエンジニアが対象
- 質問いつでも OK
- ハッシュタグは
#hbsuty
挨拶的な
- 自己紹介
- 翻訳出してる ( たくさんある
- ヘルシープログラマ
- おすすめ
- 年内
- SRE, LearningPySpark, Spark …
本日の内容
- 面白いところをつまみ食いで紹介
- 600ページ!!
- SRE としてやっているわけではないよ ( 体験したことじゃないよ, 伝聞だよ
- 翻訳した立場からの紹介だよ
- 質問を期待しているので 2 時間分は確保してないよ
- 質問はお気軽に。でも印税は答えられないよw
The SRE Book の出版
原初について
The
がついてるよ- PDFでダウンロードできる、フリーで
- Google が share していく一環で公開
- とにかく字が多い
- 読み終わるとすぐだった印象 ( hadoop の本も同感だった
日本でも
- メルカリ、スマートニュース、サイボウズ
- 大きな動きになっている
翻訳した
- マジで大変だった
- 5000円越えして高い… けど、ワード単価だと 0.0025 で Docker 本(0.0034)より安い!
- SRE 本お得だなぁ
- 歴史的な名著になることは間違いない!( と思う
- 構成大変
- エラーバジェット (エラー予算と訳す?そのままバジェットにしよう)
- シンボリックなキーワードはそのままがいいだろうということでカタカナを選択した
自己主張したところ
- サブタイトルを変更した
Google の信頼性を支えるエンジニアリングチーム
技術論より組織論
- 組織としてよく考えられている,
組織としての考え方が果たしている役割が大きい
- Google だから、というわけではなく、学べるところは多い
- チーム作りとか
- フリーランスからスタートアップまで学べる面が多い
- 組織としてよく考えられている,
目次
- 34章ある
- 半分ぐらいが組織論であることがわかる ( プレゼンテーション画面では組織論の章が赤く色分けされていた
余談 ( SREのみなさんの仕事っぷり
- 手が早い
- Google Docs の使い方がうまい, 日常的に使っている感じ
- 翻訳もスプレッドシートを使って、進捗管理された
- スプレッドシートの機能を使って、自動化されている
- 地道な自動化をきっちりやっている印象
- 信頼性 100% は目指さない、コストがかかるから
- 後世に関しては 100%を目指さざるをえない…
余談 (三人称単数の
They
- 単数形で使われていることが増えている
- He, She のように性別区分けすることを避けて(Gender neutral な表現として)、They と使っている
- 最初誤植かと思った
- 原書はその辺り気を使っている。
~~のよ
みたいな女性的な台詞回しも無くしている - Q) They はどうやって訳したの?
- A) 一箇所しか出なかったのでなんかごまかした. それより会話の方が難しかった
- 日本語だと男女がどうしても見えてしまうので、そこを気を使った、難しかった
- He とか She の部分は名前になっている, 訳した時も全部名前にした
- Q) カタカナ的なものをカタカナにするか英語にするかの判断基準 ( イシュー? issue?
- A) ケースバイケースで翻訳した、基本的には日本語にしたいよくはあった
- Hadoop はアルファベットを多用した,
- アルファベットの方が良いという反応があったが、ベンダ側から、読み方がわからないという話もあったので、カタカナよりにもしている ( 会話するときに困るという話が上がったらしい
- 本の中で統一するということは気にした、本が分かれると変わるかも
- ヘルシープログラマは日本語よりにして読み物として面白いようにした
SRE is
SRE という職種/チーム
- 基本的には運用の人
- Dev/Ops だと、 Ops 側の人
- スキルとしてプラグラミングが必須である
- Google の採用基準の 8 割ぐらいを満たしている人が必要
- Dev としてバリバリできる人が SRE に採用される
- 結構スター性がある人が採用される ( 運用だけをやってる人って訳ではない
- Dev + インフラのスキルを持っている人、ハードル高い…
- 仕事内容
- オンコール対応 ( エスカレだね
- 改善のための開発業務
- サービスの開発チームは、サービスに属しているが、SRE チームは、全社横断的に存在している
- サービスとインフラの間にいる図となる
- 1 サービス 3 人ぐらいで作られている ( @google
SRE の原則
- 信頼性、リアイラビリティに焦点が向けられている
- 信頼性とは何か、の定義が厚く書かれている
- ソフトウェアによって運用を自動化し、スケールする
- SRE チームの規模はサービスの規模に比例してはならない!! ( 原則
- サービスの複雑さがました時は、SRE チームが増えるのはあり
トイル
の撲滅- 自動化できるはずのこと、繰り返しやっていること、繰り返しても価値を産んでないもの
- 人の時間を食ってるだけ
- ソフトの力を使って解決し、時間を作り、本質の問題に時間を割くようにしよう
- トラブル時、スキルのある人が徹夜をして解決しました!
- ポジティブに語られがちだけど、否定的に取られている
- 組織で解決していきましょう
- トラブルの最中でも 17:30 にではと言って帰るというエピソードが出てくる
- 火事場になって個人に負担がかかってしまうのを、組織で対処する
- Q) Google の SRE の人数って?
- A) 不明
- 10月に Google で出版イベントやるかも?
- Goole から偉い人くるかもよ
- そのときに質問するといいかもw
- 信頼性、リアイラビリティに焦点が向けられている
休憩
hb飴おいしい #hbstudy
— トラベアー (@ginbear) 2017年7月25日
速度と信頼性、そしてデータに基づく業務判断
重要視 : 速度と信頼性
- 新しい機能やサービスを投入するペースのこと ( 反応速度じゃないよ
- 信頼性は SLO : Service Level Objective
- 開発者(Devs)は速度を、運用者(Ops)は信頼性を重要視する傾向にある
- ある種の対立関係, 緊張関係が生まれてしまう -> 解決しないとね
- SREのキーワードとして、願望は戦略にあらずという話がある、うまくいってるのを祈るだけはやめよう
- という話をしてプロジェクターが映らなくなったハプニングにつなげた
計測されたデータに基づく業務判断
- エラーバジェット & 50%ルール
- 計測して、業務判断していきましょうというのがキモだろうと見ている
- ただこの言葉をコピレばいいという訳ではなさそう
エラーバジェット
- SLO(サービスレベル目標) : 計測するデータの定義
- エラーバジェット = 1 - SLO
- Google のサービスとして完全に使えなくなる時間は原則ない、ので、投げられたリクエストに対して失敗した数を計測する
- サービスによって高める信頼性が変わってくる
- 4 半期ごとに計測する
- エラーバジェットが残っていれば、新機能をリリースできる
- エラーバジェットが無くなった婆愛、リセットがかかるまで新機能のリリースは禁止
- ルールとして決まっている、トップダウンで決めている
100%は目指さない
- 可用性は 100% は目指さない ( 普通は目指しがち
- 100%は
意味がない
- 99.99%の可用性と 99.999% の可用性の違いはユーザーにはわからない
- それよりも、他の問題が要因になることが多い
- 100%に近づける努力と見合わない
- サービスの性格に応じた SLOの定義が非常に重要
- 合理的に割り切りを行っている
50%ルール
- SREは作業時間の 50% 以上をエンジニアリング業務に割り当てなければならない
- 運用業務に時間を取られ、50% を超えると、開発チームが SREの支援に時間を当てる
- というのがルールになっている
- データに基づいて業務判断を行うことをルール化することによって、Dev/Ops の対立関係を緩和している
Q) (質問聞きそびれた)
- A) 基本 post で価を計測できるような仕組みなっている
Q) 計測手段がないものは?
- A) 最初から仮想マシン上に計測可能な状態になっている.
魔法の話はあまり出てきません
- 全体的に技術者の地味な作業の話が出てくる
- Google 独自の話って訳ではない、自分たちがどう学べるかという姿勢で読むと良さそう
- Google はソフトウェアでコントロールできる範囲が広い
- Vagrant や Terraform で似たようなことは、手元でできる
- モニタリングできる仕組みも SRE が作った
- いろんなチームに所属している SRE チームが自分たちのために作った、徐々に統一的に作っていった、成長させていった
- 自分たちがツールを作って改善してくのとあまり変わらない、というところがわかって面白いよ
徹底した自動化志向
- 自動化のメリットは「複利」
- 複利 -> 自動化によって空いた時間を使って自動化を進めるスパイラル
- まめにやっていこう
- 手動(トイル) -> 自動化 -> 自律化
- 自動化で止めず、自律化までやっていかないとね、という話が出てくる
- 複利 -> 自動化によって空いた時間を使って自動化を進めるスパイラル
- 自動化のメリットは「複利」
採用・育成
SRE の採用はたいへん
- 要求スキルは高い
- 需要に対して供給不足
- SRE のエンゲージメント、サービスの立ち上げ時、SRE が関わる(コンサル的な)、サービス開発設計前から関わる、それでも人数が足りない、
- SRE が開発したライブラリの出番!
- これを使ってくれれば、SRE 不要
- サービス判断に必要なメトリクスが取れる、ことになる。便利。
- 既存のやり方に合わせるやり方はたいへん、レールから外れたやり方のものなど
- これを指導するよりは、ライブラリを提供する
- 自動的に広がっていく
- SREは、単なるメンテナンスする人ではない、エキスパートという面がある。開発に向けてコンサルをする
教育とオンコール
- オンコール対応似なることはキャリアの一つのマイルストーン
- skill も必要だし、サービスのことも知っている必要がある
- 昔ながらの、感と経験と度胸、谷に突き落とすようなことは
よくない
としている- ドキュメント -> ポストモーテル? -> シャドウ -> オンコール
- シャドウという一緒に横で対応してくれる教育者がいる
- 推奨とアンチパターンの表がある
- 試練を与えるようなやり方はよくない、とか
- うまくいかなかった時は、個人を責めない、とか
- 人工的に障害を発生させてシュミレーソションする、とか
- シニア SRE もいる
- 組織論としてよく考えられている、個人の熱意ではなく仕組みとしてやっていく
- オンコール対応似なることはキャリアの一つのマイルストーン
障害対応とトレーニング
- 年に一度全社的にトレーニングしている
- 障害対応の手順はあるけど、やったことはない、とか久しぶりというケースはある
- たまにしかやらないことは身につかない!と認める
- 人間だもの
- 障害対応手順を、日常業務に組み込んでおく
- 普段からやっていることを、障害対応時にやるだけ
まとめ
- 自動化二よってスケーラビリティの向上、トイルの撲滅、さならなる自動化のための時間を作る
- ソフトウェアの力で運用改善
- データの定義、開発とSREチームが同じ方向を向けるようにする
組織論に注目して読んでいただけると
Q) SRO の定義がサービスと SRE でずれてしまった時はどうするか?
- A) 重要なメトリクスはほとんど同じという記述があった
- メトリクスが多すぎるのもよろしくない、なるべく共通した単純なメトリクスを推奨
- Google は Web サーバの作りが標準なので、それで統一されているかもしれない、という印象はある
Q) ライブラリを提供する仕組み
- A) Google の公式言語 4 つある, Go C+ python .. ..
- SRE が提供する時は公式言語に基づいて提供する
- Google サービスは階層構造になっている
- インフラ的な階層もある、コンテナサービス
Q) SRE は一人当たりいくつサービスを見ているのか
- A) 複数のサービスを受け持つこともあるし、一つのこともある
- 人やサービスによりそう、ケースバイケース
- オンコール対応をやっている人は 1 日に二つのコールを受けるぐらいがちょうどいい
- 低すぎても、多すぎてもよくない、というところまでコントロールしている
- 負荷の均等化をして質を保っている
- データの計測と調整に紐付いている
Q) 作業時間はどうやって計測しているか
- A) 計測方法は不明、でも計測して居るらしい
- Q) なぜ 50%
- A) 不明。50% を受け止めすぎる必要はないのでは
Q) xxx
- A) 妥当な負荷で、オンコールを遣る話が
- 一つの拠点や複数の拠点でオンコールを回す場合で異なる
- Google の場合海外にも拠点がある場合があるので、日中帯であることもある
Q) SRE エンジニア、という言葉の冗長性についてどう思うか
- A) SREngineer とか SREngineer Team と書いてある
- 表現とズレが発生し始めている
- SRE エンジニア は個人的には違和感ある
Q) 評価制度は出てくる?
- A) この本は出てこない.
- 与えたインパクトの大きさは、評価の一つらしい
Q) チーム担当の異動について
- A) あるのでは?Google ないでもあるようです ( 推測
Q) コンテナ運用の話は乗ってる?
- A) あんまり乗ってない
- Google のインフラの話は 2 章で出てくるけど、詳しくは乗ってない
- Borg の話はそんなに出てこないよ
- モニタリングの話は結構出てくる
Q) 発売に向けて一言
- A) みんな買ってね
最後に、hbstudy の設営のみなさま、ありがとうございました。 hb 飴美味しかったです。