ちくわ

ちくわにきゅうりを入れるとうまい

『第74回: SRE大全: 序章』hbstudy#74 に参加してきた

以下の勉強会に参加してきました。

hbstudy#74 - hbstudy

こちらがその本 ( 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

休憩

速度と信頼性、そしてデータに基づく業務判断

  • 重要視 : 速度と信頼性

    • 新しい機能やサービスを投入するペースのこと ( 反応速度じゃないよ
    • 信頼性は 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 飴美味しかったです。

安宅和人 (著) イシューからはじめよ―知的生産の「シンプルな本質」を読んだ

この本では、生産性を上げることを、同じ労力・時間でより多くのアウトプットを出すこと(= バリューのある仕事)としており、バリューのある仕事とは課題の質(これをイシュー度と呼んでいる)と解の質のマトリクスで表し、イシュー度と解の質がともに高い状態を指しています。

イシュー度 -> 自分の置かれた局面でこの問題に答えを出す必要性の高さ

解の質 -> そのイシューに対してどこまで明確に答えを出せているかの度合い

そして、ここで解の質を最初にあげようとするアプローチ(労働量、努力や根性で解を出すこと)を「犬の道」と筆者は読んでおり、先にイシュー度を上げるアプローチの重要性を説明しています。

理屈としてよく分かるし、(ケースとしては稚拙なものですが)何か問題解決するときに、問題内容を正確に理解せず思い込みでインプットしたのち、出した答えは何の価値もないものだったという経験は何度もあります。

働きをかけるベクトルは正しいものでなければ、その働きは何の意味もなく、当然生産性はステイどころかマイナス成長してしまいます。
(生産性 = 成果/投下した労力・時間 という方定期式で考えると、分母を無駄に増やしていることになる)

かといって問題を把握することに時間を費やしても、成果は出ないので、いかに効率的に・的確に問題を分析するかが重要になるかと思います。この本の序章以降はその辺りが書かれていました。

ただ、全体的に出てくるケーススタディが物流だったので、今の仕事に転換イメージするところで止まってしまい、序盤 〜 第1章(イシュードリブン - 「解く」前に「見極める」)あたりウンウンと頷いて読んでいましたが、後半は流す感じになってしまいました。

最後に、この本で刺激を受けた事として、以下を抜粋します。

どんなイシューもサブイシューも、答えを出して初めてそれに関する仕事が終わった、と言える。ここで大切なことは「停滞しない」ことだ。 要は手早くまとめていくのだが、そのためには次のコツを知っておきたい。

停滞を引き起こす要因として、最初に挙げられるのが「丁寧にやりすぎる」ことだ。- 中略 - 生産性の視点から見ると、丁寧さもすぎると害となる。- 中略 - 単に丁寧にやっていると、スピードだけでなく完成度まで落ちてしまうのだ。

『第4章アウトプットドリブン > 軽快に答えを出す > 回転数とスピードを重視する』より

ここでは丁寧すぎること指摘されていますが、継続的に・適切なボリュームのイシュー立てを行うことは大事だなと思うのでした。いつまでも閉じれないイシューや、定期的に見直しが必要なのにケアされていないイシューがあるケースを思い返しつつ…

伊賀 泰代 (著)「生産性」を読んだ

読書会の課題図書ということもあって、ちゃんと?通して読みました。

生産性というテーマで、前半は生産性 is 何、本当にそれ生産性あることなん?という視点で語られていて、後半になるにつれ生産性をあげるための具体的なノウハウに移っていく流れです。

紋切り型な対応を挙げてより生産性の高い手段・考え方は何かを整理して説明されていて、話の流れも読みやすく腹に落ちる事が多い印象を持ちました。 (日本の対応あるある話がどこまで実際にあるあるなのかは分かりませんでしたが…)

個人的に刺さったのは、第3章にあった「成長とは、『生産性が上がる』こと」でして、以下一部抜粋です。

自分で目標を立て、その達成度合いに応じて評価される目標管理制度について「目標を低めにたてほうが得をするおかしな制度」と言った批判がつきまとうのも、その目標が量で決められているから

-> 成果も達成目標も生産性の伸びによって設定する -> 目標上限もなく、続ければ大きな進歩となる

量ではなく質を重視する組織になる。成果の絶対量の大きさではなく、生産性の伸びを評価する組織になる — これが今後の組織づくりにおける重要なポイント

-> 生産性を評価基準に取り入れると、労働の質に意識をむけるようになる

なるほどね〜

SRE Tech Talks #2 に参加してきた

こちらの勉強会に急遽潜り込むことができました。

eventdots.jp

以下、資料たちです。

株式会社メルカリ - SRE 久保達彦 @cubicdaiya

speakerdeck.com

サイボウズ株式会社 運用本部・サービス運用部・SRE 深谷敏邦 @toshi_pp

www.slideshare.net

クックパッド株式会社 インフラストラクチャー部 SRE グループ長 星 北斗 @kani_b

speakerdeck.com

株式会社ミクシィ XFLAG™スタジオ ゲーム開発室 SREグループ 清水 勲 @isaoshimizu

speakerdeck.com

さくらインターネット株式会社 技術本部エンジニア 山田修司 @uzyexe

sssslide.com


いずれも規模の大きいシステムに対して柔軟性を持ったインフラを提供する工夫やそれにいたる歴史が語られていて、刺激と気づきと反省を得ることができました。

今の業務を改善をしていく姿勢は勿論ですが、積極的にソフトウェアで解決してレバレッジを効かせていくと、より平和な世界と品質の高いサービス提供の基盤を提供できそうです。

(英語だけど) オライリーの書籍「Site Reiability Engineering」も無料公開されていますし、SRE の普及はより進みそうです。 http://www.publickey1.jp/blog/17/googlesite_reliability_engineering.html

しかし、pagerduty の導入率高いなー。

Wi-Fi 対応の体重計 Withings Smart Body Analyzer を購入した

前々から欲しいけど高いなぁと思った居たところに

と、ホシハヤトさんがつぶやいてるのを見てセールを知り、直ぐに奥さんにプレゼン。なんとか説得に説得を重ね購入できました!ありがとうございますホシさん!!

 

そして購入したのはこちらです。 買ったのはホワイト。

Withings Bluetooth・Wi-Fi対応 体重計 Smart Body Analyzer WS-50 体脂肪/心拍数/室内環境分析 ブラック 70023101【日本正規代理店品】

 

続きを読む

手元のテキストスニペットを alfred にもってきた話

snippet 便利ですよね。 長らく peco + zsh を使って CUI 上でスニペット運用をしておりました。 まさに、以下の仕組みです。

blog.glidenote.com

これはこれで非常に便利なのですが、本番サーバに入っている場合は都度ローカルターミナルを開いて(或いは移動して)、スニペットを出すコマンドを実行し、セレクトするため、ちょっとアクションが多いなという所感を持っていました。

そんな中、alfred version3 がリリースされました。

続きを読む

ブログお遍路を経て

ちょうど一ヶ月前、この投稿より、毎日ブログを書くという企画を会社の仲間とやっていました。

blog.ginbear.com

日が跨ったりしたことはありましたが、なんとか(この投稿を含めて) 31 投稿、欠けること無く達成した事になります。
自分の投稿を振り返ってみると、

  • 趣味のクライミングネタ(これは別のブログ グミうまい に書いていた) * 7 投稿
  • AtCoder ネタ * 7 投稿
  • 読書ネタ * 4 投稿
  • IIJmio に乗り換えた話 * 4 投稿
  • 日記 * 3 投稿
  • mackerel ネタ * 2 投稿
  • その他 * 3 投稿

約半分が趣味のクライミングと AtCoder に頼ってきた感じです。確かに振り返るとネタが無いに AtCoder を解いたりクライミングの記事を書いた記憶があります。

2015年のブログ投稿が 2 つという事を考えると、圧倒的に増えました。とりあえずネタはなんでも良いとすれば、生み出せるものなんですね。

発見したこと

お遍路前は、一つの投稿の内容に結末や結論的なものが無いとダメなんだという個人的な障壁があり、書こうかなと思いつつ記事にせず流れてしまった事が多々ありました。

今回投稿した中に、(IIJmio に乗り換えた話)を三分割して投稿したのですが、この様にゴールまで行かなくとも、ある程度話が進んだ段階で纏めて小出しにしたほうが、まとまりが良いという気付きがありました。 ログローテーションで言うと、容量でローテートするのではなく、時間でローテートする感じです。伝わりにくいですね。すいません。

投稿内容への考え方

例えば日記関係の投稿()に関しては、この投稿は果たして何のために、誰に向かって書いてるのか腹に落ちない所があったのですが、細かい事を考える前に書いて見ました。

日記に関しては未だに明確な目的を持って書くことが出来ていないのですが、世界の何処か自分とは全く考えが違う人の心とか考えとか参考になるのではと思う事にしました。インターネットってそういうものだよね。という感じで。

ある記事単体では何の参考にもならないけど、インターネットという媒体を通すことによって別の意味が帯びてくる事もあるかもしれないですよね。

今後も続けるか

家族の時間を少し犠牲にした部分もあったので、今後も毎日というのは厳しいと感じました。

ですが、自分の中の投稿ハードルがいい意味で壊れたので、今後の投稿ペースは上がるのではないか...と思う。たぶん。きっと。恐らく。