本を読む会 SRE サイトリライアビリティエンジニアリング #5 ~トイルの撲滅

読み会5章「トイルの撲滅」予習ログです。

#5 トイルの撲滅

Eliminating Toil

  • "If a human operator needs to touch your system during normal operations, you have a bug. The definition of normal changes as your systems grow."

読み解きたいこと

  • トイルとはなにを指すのか
  • Google はどうしてこの内容をあえて章として取り上げるのか
  • トイルとは具体的にどういった作業を指すのか
    • SREに聞いてみたい

読書メモ

5.1 トイルの定義

  • トイル
    • プロダクションサービスを動作させるエンジニアリングに関係する作業
    • 自動化が可能で、戦術的で長期的な価値がなく、作業量がサービス成長に比例
  • オーバーヘッド
    • エンジニアリング以外の作業。プロダクションサービスの稼働に直接関係しない管理上のお仕事
      • e.g. 定例チームMTG, 人事評価作業、目標設定や選考課題考案や事前MTGなど
手作業である
  • e.g. 何らかのタスクを自動化するためのスクリプトを手動で実行するようなこと。確認や実作業にひとの時間を使うようなこと
繰り返される
  • e.g. 3回以上同じ作業を繰り返し繰り返し行うようなこと。もたらされる成果やアウトプットは同じもの
    • 1~2回程度であればトイルと言わない。また新しい気づきや問題解決や解決策に至る作業はトイルと言わない
自動化できる
  • マシンが人と同じように行えるタスク、またそのタスクの必要性をなくすことができる仕組みが作れるようなら、その作業はトイル
    • ひとの判断を要する作業はトイルではない 。ならば選考対応はトイルじゃない。オーバーヘッド
戦術的である
  • 戦略や予測の基づくものではなく、解決にいたるフローの中の作業でもなく、割り込みでスタートして問題発生時の対応作業としておこなわれるもの
    • ゼロにはできないが最小限にはしたい
    • 別のサービスで同じ障害がなんども発生してしまうようなこと？
長期的な価値を持たない
  • タスクを終えた後も、サービスが成長・前進しない
    • 古いコードや設定に踏み込んで整理改善し、サービスにとって恒久的な改善が加えられればトイルではない
サービスの成長に対して O(n) である
  • サービスの成長（トラフィック量、ユーザ数）とともに作業量も増加してしまうようなタスクはトイル
  • 理想的な管理と設計がされたサービスは、そのリソースを追加する作業のみで、他の追加作業なしに1桁程度は成長ができる

5.2 トイルは少ない方がよい理由

この節は Googleの信念を感じる。

  • トイルの作業性質は、SREの戦略・存在意義に反するから
  • SREにとってエンジニアリングとは、サービスをスケールさせる作業であるから

そのためにやっていること

  • SREの目標に、トイルに使う作業は作業時間全体の50%以内に抑えることを掲げる
    • 各SREの作業時間の最低50%は、将来的なトイルの削減またはプロダクト成長に寄与するシステム開発に充てる
    • そういった機能開発は、信頼性、パフォーマンス、利用率の改善目的でおこなうことが普通で、この作業はしばしばトイルを削減してくれる副次効果がある
  • SREの採用時に、いわゆる運用作業チームではないことを明言し約束する
    • そして運用作業チームにならないよう組織チーム全体で取り組んでいく
Googleでのトイルの計算
  • トイルのなかで最も多い作業は割り込み。緊急ではないサービスに関するメッセージやメール、notify
  • その次にオンコール（障害対応）、次にリリースやプッシュ
  • SREのトイルが多すぎる場合
    • 特定のSREのトイルが多すぎる場合は、マネージャがそれぞれに負荷分散できていないことを示す

5.3 エンジニアリングである条件

エンジニアリングとはなにか

  • 人間の判断を必要として新しいものを作ること
  • サービスに恒久的な改善を加え、戦略により導かれるもの
    • クリエイティブでイノベーティブであり、問題や課題を解決するために設計主導のアプローチを取る
  • 汎用的である/横展開が可能である

以下はSREの活動。SREがトイルに割く時間が50%を大きく上回る場合は、何が問題なのかをしっかりと確認しないといけない。

ソフトウェアエンジニアリング
  • SREがコードを書き、新しいツールやフレームワーク、自動化スクリプトを作り出すこと
  • サービスの信頼性やスケーラビリティにダイレクトに働きかけ、サービスに恒久的な改善をもたらすエンジニアリング
システムエンジニアリング
  • プロダクトのシステム設定、設定変更、システムのドキュメンテーションの作成
  • 一度の作業で改善効果が持続できるような作業
    • e.g. モニタリングのセットアップと更新、ロードバランシングの設定、サーバ設定、OSのパラメータチューニング、開発チームへのアーキテクチャ、設計、プロダクト環境に対するコンサルティング
トイル

上述の通り

オーバーヘッド

上述の通り

5.4 トイルは常に悪なのか?

  • 少量であれば悪ではない、中にはトイルを楽しめるSREもいる
    • いち早く達成感をもたらしてくれる類のタスクでもある
  • SREのみならずエンジニアにとってゼロにはできないものであることを認識しておきたい
  • トイルが実業務の半分以上あるいは大量に発生する場合は、問題視したい

トイルが悪になる理由は以下。

キャリアの停滞 (個人)
  • トイルを積み重ねても、サービス・個人どちらの成長にも繋がらない
モラルの低下 (個人)
  • あまりにトイルが多いとSREとして業務をすることが嫌になってしまう ><
    • 切ない
混乱の発生 (SREチーム)
  • SREが発揮する本来の成果/Site Reliabilityやサービスをスケールさせることに時間を割けない。SREの存在意義が自他ともにわからなくなってしまう
    • 切ない
進歩速度の低下 (SREチーム)
  • トイルが多すぎると SREチームの生産性が下がる。火消し作業ばかりに注力し本来のプロダクト機能開発速度の低下=サービス成長の機会損失
    • 切ない
習慣づけ (SREチーム)
  • SREが頑張ってトイルをやっつけすぎるとトイルに対してSREの活躍を期待するように
    • トイル対応はSREの主たるミッションではないのに切ない
摩擦の発生 (SREチーム)
  • トイルが多すぎることによるチーム全体のモラル低下、SRE個々の摩擦
  • 切ない
信義違反 (SREチーム)
  • 大量のトイルは、新規作用されたSRE、あるいは異動者に対する信義に関わる

5.5 まとめ

  • 優れたエンジニアリングで、毎日少しずつトイルを無くしていこうという気概を持とう
  • そのことでサービスをクリーンアップし、SREの労力をスケーラビリティの向上と次世代サービスのアーキテクチャ設計、ツールの構築にシフトしていこう
  • そしてイノベーションを増やし、トイルを減らしたいね

参考

www.youtube.com

わかったこと

  • SREにとってトイルの存在
  • トイルがもたらす影響
  • トイルを減らすために
    • SREの技術力、DevOpsの対立を生まない体制と仕組みづくり、どれが欠けてもいけない。トイルを削減するという目標を掲げ、削減に必要な材料は同時に進化させるという意思が重要そうだ
      • 自分の職種やチームにもトイルはある。判断を必要としない手作業や繰り返しを「仕方なし」で済ませている。気に留めないといけない

感想

「私たちSREにとってこれはトイルです」と決めて「トイルによりこんな悪影響が及びます」なので「撲滅したい」と発信することで、自分たちのミッションをブラさないとするGoogle SREの信念を感じた。一貫している。
と同時に、"5.4 トイルは本当に悪なのか" の節では SRE の悩みを垣間見せてもらった気がした。

トイルを撲滅するための案として「SREのクリエイティブやイノベーティブマインドを広報し、周辺理解の醸成を進める」を挙げてみたい。SREがパフォーマンスを発揮する対象が浸透すれば、エンジニア全体でトイルを撲滅するあるいは分担できる環境が整いやすくなるかもしれない。
他に、トイルから話が逸れるが、SREのクリエイティブは組織や担当サービスにより異なるイメージがある。一人ひとりのSite Reliability Engineer が、まだ新しい職種であるSREのありようをそれぞれの環境で育てていく、というおもしろさがありそうにも感じた。

SRE本を興味深いな読み返したいなと思える点として、別職種である自分にもあれこれと置き換えて思考できるというのがある。

参加者 : missasanさん, yuukiさん

自分傾向の記録

メモを見返していたらゲーム感覚で回答したアンケート結果が出てきた。それぞれ時期が違うにも関わらず、傾向が似通っているように感じるので記録しておこう。

自分のことはなかなかわからないものですね。

ストレングスファインダー

2017年

  1. 個別化
  2. 共感性
  3. 収集
  4. 信念
  5. 親密性

16 Personalities

2016年
“仲介者”型の性格 (INFP-A / INFP-T) | 16Personalities
読み返して笑った。現実離れした雰囲気を感じる。

仲介者型の人達は、他の性格タイプよりも、よく思いにふけり、楽しみながら物事をあれこれ想定したり、哲学的な事柄について思い巡らせたりします。
放っておくと、まるで隠者のように引きこもったまま連絡が途絶え、友人やパートナーが、多大なエネルギーを費やして、現実世界に連れ戻すことになります。

職業適性

2015年
「哲学者」外向性がゼロに近い。「知覚」と「判断」は半々なのかな。

珈琲美美@福岡 のこと

福岡は大濠公園近くの珈琲美美 について書く。

珈琲美美を知ったきっかけは、珈琲特集雑誌で ELEPHANT FACTORY COFFEE （エレファント ファクトリー コーヒー） - 河原町/コーヒー専門店 [食べログ] のマスター 畑さんが語るインタビュー記事だ。
インタビューでは、Elephant Factory Coffee のこだわりや全国の珈琲専門店を巡られたこと、その中で影響を受けた自家焙煎珈琲店を3つ挙げられたいた。尾道の珈琲店（名前忘れ）「大坊珈琲店」そして「珈琲美美」。うろ覚えであるが、畑さんのコメントはこうだった。

福岡の珈琲美美さんの珈琲はクオリティが高い。なによりもマスターが30年間店に立ち、切り盛りをしている。かっこいいんですよ。

今は閉店してしまった南青山の名店「大坊珈琲店」は自分も大好きなお店だったので、福岡に出向く機会があれば珈琲美美に行くと決めた。

時が経ち、友人が福岡を訪れた際に「落ち着きのあるお店」として店前と珈琲の画像を投稿された、その場所が偶然にも珈琲美美だったのだ。
うおーそこは私が行きたいと思っていた珈琲専門店です！
ずっと行きたいと思っていたお店が一気に身近に感じられてホクホクしたのを覚えている。

それからさらに1年が過ぎて、2016年夏に会社の出張で福岡を訪れることになる。もちろん珈琲美美が脳裏を過ぎるのだった。

出向いた日、博多駅から地下鉄で大濠公園駅で降りるべきがぼんやりして下車し損ねたりした。無事下車して、池のほとりを経由して珈琲美美まで散歩。とても蒸し暑い日で強い日差しに辟易した。池近くのベンチに座って温風に吹かれながら亀と鳥を眺めた。

大濠公園を抜けて左に曲がり、すこし進んだ先に珈琲美美がある。左？右かも。

お店は緑の多い並木道通り沿いにあり、店前には珈琲豆を焙煎した香りがずっと漂っていた。1Fは焙煎に使われる機械が収められた作業場で2Fに案内された。店内はクラシックな色調で統一されており、木の香りと珈琲の香りが半分ずつする。カウンターの向こうにマスターと奥様が並んで立っているのが見えた。
フルーツケーキとマザグランをオーダー。珈琲は奥様の手によってそれはとても丁寧に淹れられた。作業工程の一部始終を観察し、見惚れていた。時々マスターの森光さんが指示出しをされている様子が見えた。
マザグランは氷の入っていないタイプの濃厚なアイスコーヒーで、冷やす工程でシェーカーが使われていた。当時の画像が全て失われてしまい残念。よく冷えたマザグランは綺麗にコーヒーとミルクが分離されて香りはもちろん見た目にも美しかった。
フルーツケーキはたくさんのドライフルーツとナッツが含まれてどっしりだ。上品な甘さが好みで今すぐたべたいとなる。
のんびりとした時間が流れるおすすめのお店です。

今年になって、2016年12月に珈琲美美のマスター森光さんが亡くなられたことを知った。
大坊珈琲店のマスター大坊さんが「僕は珈琲屋だけど、彼は珈琲だった」と森光さんについて語られていた。
ああいいな、これが知己というものだな、と思う。

珈琲美美は森光さんの奥様が引き継がれている。いずれまたマザグランとフルーツケーキをいただける機会があるとうれしい。


大坊珈琲店

大坊珈琲店

珈琲屋

珈琲屋

本を読む会 SRE サイトリライアビリティエンジニアリング #3

読み会予習ログです。

第II部

Google - Site Reliability Engineering

  • SREが仕事を進めるうえでの原則が語られている
    • SREのオペレーション全般
    • SREの振る舞い
    • SREの関心ごと

#3 リスクの受容

Google - Site Reliability Engineering

読み解きたいこと

  • SREのリスクマネジメントのあり方
  • SREのサービス/システム視点、関心

読書メモ

まえがき

  • 信頼性は大切であるが100%を目指してはいない。過度の信頼性はコストである
    • 新しい機能開発やユーザへのプロダクト提供速度が落ちることになる
  • 「リスクマネジメントとデバイスとのバランスを鑑みたうえでユーザの満足度を維持する=信頼性」と定義できそう？

3.1 リスクの管理

  • 信頼性を担保するためにかけるコスト
    • 冗長なマシン・コンピュートリソースにコストをさく
      • 冗長化することで、メンテナンスのやりやすさ、パリティコードブロックを保存するための領域を持てる
    • エンジニア組織が、障害リスクを減らすためのシステムや機能を構築するためにエンジニアリソースを当てる
  • つまり信頼性の担保＝リスクを管理することと言える
    • リスクマネジメントをしっかりとおこなう組織とシステム整備が重要
  • リスクへの考え方
    • 連続的なものであり、信頼性を高めるためのエンジニアリングと障害許容レベルの定義を決める
    • それは（おそらく）サービスにより異なる。ビジネスが許容できるラインをしっかりと理解していることが求められる
  • 可用性のラインを理解することでリスクマネジメントを行う

3.2 サービスリスクの計測

  • システム（サービス）ごとにどういったメトリクスを計測すればよいかを見いだすことは信頼性の担保に非常に有益
    • パフォーマンスの改善、劣化の追跡が可能になる
  • 計画外の停止時間
    • リスクの許容度をもっとも単純明快に表す方法。計画外の停止時間は、サービスの可用性が実際のところどの程度求められるのかによる
  • Googleでは時間を基にした可用性は定義していない（世界中で展開するサービスのため、時間を基にしたメトリクスにあまり意味がない）
    • 総リクエスト数に対する成功したリクエスト数を可用性を測るメトリクスとしている
  • 四半期単位で可用性のターゲットを設定。そこから週・日単位にブレークダウン
    • 定量目標の設定は四半期ごとに見直すくらいがちょうどよいのだろうなあ半期だと長すぎる

3.3 サービスのリスク許容度

  • Googleではサービスのリスク許容度は明確に定義していない
  • するなら、SREがビジネス観点（事業側の定量目標やクライアントとの契約内容、パフォーマンス）を把握し、エンジニアリングで解決可能な目標に変換する必要がある
  • SREとプロダクトマネージャーの協働が必要
  • とはいえ簡単なことではない
    • プロダクトや事業サイドの責任構造はあっても、インフラストラクチャサービスの構造がないあるいは一致しないことがしょっちゅう
      • サービス側と人事との難しさと共通しているように感じる
      • (CRE目線なら）クライアント先の事例を集め、サービスやシステム構造によって何をプライマリメトリクスとするかの提案ができるとよいのだろうか

3.3.1 コンシューマサービスにおけるリスク許容度の明確化

  • SREとプロダクトマネージャ（ビジネスやユーザーに対する可用性/可用性をどうみなすかについて議論できるポジション）の目線合わせが重要
    • プロダクトマネージャにはある程度システムやSREの思想がわかっているとなおよい
  • 双方で明確化するリスク許容度
    • 必要な可用性レベル
  • 障害の種類とサービスへの影響
  • 「リスク曲線上にサービスを位置づける上で、サービスコストはどのように利用できるか」 > 日本語の意味がわからなかった
    • How can we use the service cost to help locate a service on the risk continuum?
      • リスクは連続して起こりうるものだと定義した上で、サービスコストをどこまで払うことが可能であるか、と訳せそう
  • 可用性を満たすために考慮すべきメトリクスがなにであるかの合意形成
3.3.1.1 可用性のターゲットレベル

可用性をどう設定するかは、そのサービスがユーザに提供する機能と市場におけるサービスの位置付けに依存。またはサービス機能の開発ステージ（途上なのか過程なのか充足なのか）にも依る。

  • ユーザーが期待するサービスレベル
  • サービスの収入構造
    • ビジネスモデル
  • 競合との差
  • toB or toC
3.3.1.2 障害の種類

「上り一日下り一時」「好事 門を出でず、悪事 千里を走る」を想起させ、SREの役割には頭が上がらない。

  • 障害の種類により、障害レベル、ユーザに対する信頼度、ビジネス影響など複数の影響範囲を知った上での判断が必要
3.3.1.3 コスト

コスト意識を数字で可視化。なんとなくふわっとではなく。

  • 可用性を1桁改善したら収益がどれだけ増すのか？とか
  • その収益増加は、信頼性を担保するためにかけるコストに見合う価値があるか

収益で測れないケースでは、ISPのバックグラウンドエラー率を考えることも有効。はてなでもそういったケースは多そう。

3.3.1.4 サービスの他のメトリクス

リスクマネジメントをやる上で、可用性以外のメトリクスも考えておけるとよいですよというお話。

  • 例、Google Adsにおいては、Web検索機能の速度
    • 数字だけじゃなくて、人の体感速度にまで気を使っているのがさすがー
  • サービスにより（Ads とAdsense) 優先づけができる
    • Adsenseはパブリッシャ側のレイテンシにもよるため、Adsに比べるとほんの少し緩めで設定できますよん、など

3.3.2 インフラストラクチャサービスのリスク許容度の明確化

コンシューマサービスとの基本的な違いはインフラストラクチャのコンポーネントの複雑さ。複数のクライアントを持ち、各クライアントの要求が多様。

3.3.1.1 可用性のターゲットレベル

システムの可用性定義は、複雑かつ大規模な分散システムの特性や働きを理解するところから。どのメトリクスを重視するかもことなりそう。より高い信頼性が求められることが多い。
インフラストラクチャのシステムの要求を理解するには、リクエストキュー の状態を調べてみるのがよい。 https://wa3.i-3-i.info/word14716.html

3.3.2.2 障害の種類

システムたちそれぞれの仕組みと特性の違いについて。

  • 低レイテンシのユーザにとっての成功は、オフライン分析に関心があるユーザにとっては失敗。
3.3.2.3 コスト > 要確認

前半の記載内容がよくわからなかった。
システムに何をさせるか（どんなデータを持たせて、そのシステムにどんな仕事をさせるか）により、何をコストとみなすかは変わるよという話？
システムを分散化し、持たせるデータとシステムの特性により、システムごとの可用性と信頼性を設定していくことが大事よ、と書かれてある気がする。

3.3.2.4 例）フロントエンドのインフラストラクチャ

いくらインフラストラクチャレベルで信頼性可用性が担保されたとしても、サーバサイドの例えばリバートブロキしやロードバランシングが含まれるようなシステムの信頼性が提供されていないと意味がありません、という話。
リスク許容度は、単眼的一役割的に判断するのではなく、複眼的に議論判断する必要があり、それによりリスクマネジメントを敷いてそれぞれの可用性を設定する必要がある。

3.4 エラーバジェットの活用

プロダクトチームとSREの典型的な認識の分断例。

  • ソフトウェア障害の許容度
    • Dev vs Opsのおさらい
  • テスト
    • 開発速度とシステム信頼性のバランシング
  • プッシュの頻度
    • デプロイ作業。たくさんデプロイしたいプロダクトチーム/デプロイ頻度が高まるほど障害懸念を予想できるSREチーム
  • カナリアテストの期間と規模
    • 新機能のリリース時における昨日全体のQAのようなもの？

プロダクト・SREチーム双方にとって最適なバランスで価値のあるサービス・システムを提供するために、双方による交渉ではなく、客観的かつ明確なデータで判断できることが望ましい。そうすることで障害に対するリスクマネジメントをプロダクト/SREチームで合意できるようにしようね

3.4.1 エラーバジェットの形成

Googleのプロダクトチーム・ SREチーム間のエラーバジェットのやり方。

  • プロダクトマネージャによるSLO(サービスレベル目標/Service Level Objectives)を規定。四半期間に期待するサービス稼働時間を設定
  • 実稼働時間は、モニタリングシステムで計測
    • Mackerelの出番か
  • この2つの数値差が、3ヵ月間の「損失可能な信頼性」と「予算」残分となる
  • 稼働時間がSLOを超えた場合は（うれしい）つまりエラーバジェット残分がある場合は、新たなリリースをデプロイできると解釈可能
3.4.2 メリット

適切なエラーバジェットを設定することにより、SLOに対する双方のコミットが高まる。
エラーバジェットの消費が高い場合は、SLOが正しい内容であるかを照らす基準にもなる。その場合はSLOを緩めるなど、サービスの現状に適した選択肢を判断するための材料としても使う。

www.slideshare.net

わかったこと

ふんわりです。

  • サービスの信頼性担保＝リスクマネジメントと言えそう?
  • サービスの特性とビジネスモデルにより、優先すべきリスクととってもよいコストを定義しておけるとよい
  • SREはコンシューマ、インフラストラクチャ、両サイドのリスクを理解しておく必要があり、障害時にはリスクの度合いによりどこにコストを割くかを的確に判断する必要がある
  • エラーバジェット＝SREとプロダクトチーム間で共同所有する指針
    • エラーバジェットがあることにより、リスクとコストを双方の尺度で判断し、同じ目的に到達することができる

感想

SREチームは技術領域の幅広さだけでなく、サービスについても広く多角的に認識している必要があることを知った。じゃないと、何をメトリクスにするか、エラーバジェットの作成、障害時に即時適切な判断ができない。手術を担当する外科医、症状から病を推測する医師、航空機におけるパイロットに似ている。
「サービスの信頼性を担保することはリスクマネジメントを徹底することである」逆説の考え方が興味深い。いま何をすべきかを決める時に、何をしないか何を捨てるかを考えるのだ。
Googleはその判断基準をデータや数値重視を徹底することで知られるが、そのことを実感できた章だった。

  • 参加者　missasanさん, yuukiさん, tomomii

「道をつくる」その後の思索

昨年末の WSA研#1 縁側トーク「道をつくる」発表から半年が過ぎた。

あの時の私はWSA研に集う皆さんに向けてお話をしながら、心の中で自分はこうありたいのだと自己表明していたように思う。そして参加者皆さんがどうありたいのか聞けるとうれしいとも考えて、ニールス・ボーアの言葉を借りて、このあとの発言は断定ではなく質問です、と伝えた。

発表体験を経て自分の思考フローが少し変化したように感じている。
どう変わったかというと、縁側トーク以降 しんどいなぁなんだか疲れたなぁと感じる時にふと自分の発表内容を思い出すようになった。一人振り返り会の回数が増えて、自分のありようで迷うことが減った。自問自答がスタートし、脳内で一定のフローが流れ、しばらくすると靄が晴れて視界が広がる。こんなイメージ > tired > questioning > observing/deep thinking > for what > action image.
碩学の思想と自身の考えを言葉にして発表するという体験が、ほんの少し自分に変化をもたらしたみたいだ。この実感が興味深い。

脳がトーク内容やいまの実感を都合よく編集しないうちに、未来の自分のために、話した内容のうち「個」を考える際に辿った言葉と思索を書き留めておきたい。

道をつくる：はじめに

以下、トークで使う「道」「研究」「個」はこう定義します。

  • 道
    • あり方 (being), 道理
  • 研究
    • 研ぎ澄まし究めること。新しい事実や解釈を発見すること
  • 個
    • なんらかの技術において専門領域をもつ個人
    • 専門領域や研究分野で、新たな価値を生み出すことにチャレンジを厭わない

紀元前後の思想家や哲学者の書籍を読むと「道」の解釈は東洋と西洋でニュアンスが異なることがわかります（下表参照）。東京大学東洋文化研究所 安冨教授の発表でその違いを聴くことができます。 > 安冨 歩「「道」とは何か？ ：『論語』と『老子』の世界観」ー東洋文化研究所公開講座 2017 「アジアの知」 - YouTube

東洋（老荘思想） 西洋
being to be or not to be
一本道の哲学 選択の哲学
全体を捉える、誰しもが行きつけばよい、一本道ひとそれぞれの道、道を間違えても迷ってもよい、間違えて戻ってこないのがアホ、自然派生的で感覚的 全体を分解して個別に理解、よい選択をすれば天国/悪い選択をすれば＞＜、現代社会はこっち(受験、就職、経済、法..）、合理的で論理的
参考資料「論語」「老子」など 参考資料「自省録」「君主論」など

縁側トークで使う「道」は、老荘思想で語られる道 (=being) を前提にしています。理由は、自分が傾倒してきた科学者の思想や考え方が、論語や老子に書かれている内容と似ていることに気づいたからです。科学者の著書を思想にフォーカスして読むうちに、ノーベル物理学者 湯川秀樹博士は幼少期から漢文や老荘思想に親しんでいたことを知りました。たしかに湯川博士の著書や専門誌では「道」の思想が滲むフレーズを多く見つけることができます。湯川博士は物理学者になる以前から、老荘思想に親しい考えをしてきた方なのでしょう。

・ただ流行を追っているだけというのはつまらない生き方です
・今日の真理が、明日否定されるかもしれない。それだからこそ、私どもは、明日進むべき道を探し出す
・1日を生きることは、一歩進むことでありたい

ノーベル物理学者  湯川秀樹

調べを進めるうちに物理学者 アインシュタインやニールス・ボーア、哲学者ヴィトゲンシュタインも東洋的な思想に関心を寄せていたことがわかってきました。このことは偶然ではなく、研ぎ澄ましてものの理を見つめ、新たな価値や解釈を見つけ出す人たちに共通する思想かもしれないと考えています。

道をつくる

私たちがなんらかの専門領域を突めようとするとき、碩学の思想や自分の経験が役に立つかもしれません。上述した「道」「研究」「個」の定義を心に留めて、私たち個のありかたを3つの問いでお話します。

  1. 自分だけの道をつくる、語る
  2. 自分の考えをもつ
  3. 孤独をおそれない

1. 自分だけの道をつくる、語る

自分の時間や考え、生き方において、他者の意見を参考や気づきの材料にしても、引っ張られる必要はないとお伝えしたいです。立場や言葉が強いひとのまねをする必要もありません。科学者をイメージしても、素敵だなかっこいいなと感じるひとも、独自の歩みを進めているように見えます。
自分を見つめようとする点で、キャリアコンサルタント資格取得の学習過程のエッセンスが活きそうです。ひとのキャリアを考えるフローは一本道の考え方が軸であり、老荘思想と重ねて考えられました。自身の強みを考える過程で、自分のストーリーを語ることを重視しています。

  • 過去に見つける
  • 現在を見つめる
  • 未来を見とおす

過去から連続する時間の積み重ねが今の自分を作っているとしたら、じゃあ今まで自分はどんな時に喜びや感動を感じていたでしょう？自分を突き動かしてきた思いや考えは、過去のどの経験や感情と繋がっているでしょう。自分の源泉はもしかしたら過去に見つけられるかもしれません。過去と今を見つめて、これからの自分をつくっていく。そんな考え方を心理学とカウンセリングのアプローチで学びました。

少し話が逸れますが、自分の時間を生きることは脇目もふらず前に進むだけではありません。寄り道をして、時には失敗をして、その道中で、感動・喜び・楽しさを見つけて小さな成功を味わう。そういったことが人生を豊かなものにするのだと思います。
疲れたときは立ち止まって休めばいい。自分のペースでよいのだと思います。先を急ぐ旅ではないはず。立ち止まる時には、そこに意味があるから足元を見て靴ひもを確認したい。ほどけたままの靴ひもでは長い旅は歩けないし、走れば転ぶし、走らなくてもひもを踏んで転ぶかもしれない。もしも転んだら、また立ち上がればよいのでしょう。

自分の経験を無にしない、他者のまねではなく自分の経験から学ぶという姿勢。自分が信じる道を自分の歩調で歩いていきたいものです。

2. 自分の考えをもつ

1. をするためには、自分の考えをもつことが大切です。何かに気づいた時、他者から何らか刺激を受けた時、その事象に対して自分はどう考えたか。事あるごとに自分の中で考える癖づけをしておけると、その事象が自分にとってどんな意味があるか意味付けしやすいように思います。ショウペン・ハウエルが「思索がない読書に意味はない」と書いているのは興味深いところです。著書「読書について」で、多読は迷いのもとで悪本は読んじゃダメと言い切っています。
自分の考えをもつことを意識付けできそうな方法をいくつかあげます。もっといろいろありそうなので、自分のやり方を見つけてみるのも楽しいですね。

  • 問いを立てる
    • 問いを立てる勇気を持つ
  • 論理を上手に使う
    • 全体像から筋道立てて（なんでそう考えるのか？を考えることで）見えてくるものがありそう
  • 言葉を鍛える
    • 自分の考えを整理し、他者に伝えるため
  • 頭の外に出してみる、議論をする
    • 脳は自分の考えであっても言葉や文字にして外に出してみないとうまく理解できないらしい。また、議論をすることで別の視点が得られ、理解が深まる

自分の考えや問いは、他者に伝えようとしたり文章にすることで、やっと形をはっきりさせることができるのかもしれません。

自らの考えを持ったうえで、様々な意見に出会う。いろんな物の見方に出会う。新しい言葉や新しい意味の広がりに出会う。そうしてはじめて、自身のより深い思考に出会えることがありそうです。思ってもみなかった場所に足を踏み入れることができるかもしれない。自分と異なる領域や別分野の考えを取り込むことも意識したいです。

3. 孤独をおそれない

言葉の通りです。
これまでに知った科学者や哲学者で、孤独じゃないひとはいませんでした。アインシュタインはあまりにも未来を見通していたために他者に理解されず孤独であった、と湯川著書に記されています。湯川博士もヴィトゲンシュタインも自身の孤独について語る文章があります。WSA研の皆さんだって、研究者ではない私だって同じだと思います。
研究をする、まだ名前がない技術分野を突めようとする時に、先が見えずわけもわからず一人で苦しいと感じることがあるかもしれません。そんな時は孤独を友だちにしたい。
何かを突めるとき、孤独から逃げない姿というものに美しさを感じます。私はそういったひとの孤独に気づきたいし応援したい。

  • 自分のビジョン、志の舵を握るのは自分
  • 先を見通し、自分の技術や言葉を語ることは孤独。すぐには理解されないことも
  • 他者の同意や期待通りに生きたら、他者の人生になってしまう
  • なにをするか、どう考えるかの決定権は自分

道をつくる：むすび

発表に至った自分のこれまでを記します。

高校1年生の時に読んだノーベル物理学者 湯川秀樹著 旅人―湯川秀樹自伝 (角川文庫）の一文に魅せられ、科学に纏わる書籍を好むようになりました。

未知の世界を探求する人々は、地図を持たない旅行者である

専門書は理解できないため物理学者の書いた随筆を読み、量子力学のりの字も分からずアインシュタインを知り、科学者の端的で美しい文章をノートに書き留めていました。読んでいると森の中を歩いているような静かな気持ちになれるので。
科学者が棲む世界は、開高健氏の言葉「成熟するためには、遠回りをしなければならない」そのもので、迷うことに対する恐怖が和らぎ、ものの理を突き詰めることの意味を知れたように思います。科学者のものの見方は刺激的でユニークで、物理学者 ファインマン博士の著書はとりわけ笑いながら読んだ覚えがあります。

ものごとの本質を捉えようとする視点や知らない解釈や新しい定義を知るうちに老子や論語を読むようになり、いつしか私も自分の道を歩んで生きたいと思うようになりました。道に迷いながらも美しいなにかを見つけられる生き方に憧れがあります。
こんな自分が、技術領域の研究会でお話させてもらう機会をいただくことができた。体験をきっかけに自分が少し変わった実感がある。人生捨てたもんじゃないな〜と思えます。

ある夢が現実化する過程

5月が終わる。年初に書いたエントリを読み返していた。
2018年 - Words fly away, the written letter remains.

抱負を書いたがまだ一歩を踏み出せていない。踏み出す方向も決めかねている。大丈夫？大丈夫じゃない気がする。「途中」で検索してみた。

途中
物事を始めてから終わるまでの間。まだ終わらないうち。中途。

途中で検索をして、中途が出てくるのはおもしろい。次は「過程」で検索。

過程
物事が変化し進行して、ある結果に達するまでの道筋。プロセス。進化の過程

変化し進行して、結果に達するまでの道筋。進化の過程。ほお。

たぶん大丈夫だろうと思えた。自信はない。でも直感にはこれまでの自分の経験や価値観が詰まっているだろうから、今はマイペースに歩みを進めることにする。自分の直感はまあまあの確率で当たるのだし。

情報の波にのまれると不安になるから新しい分野の本をゆっくりと読み進めている。それにより新しい価値を知れることに喜びを感じる。ずっと先の自分像はあるけれど、一気に結果を出そうとは思わない。今日も明日も、毎日は結果ではなく過程であり、トレーニングをしていくように積み重ねて近づいていくのだ。

ここまで書いて、学生のころに図書館で見かけてノートに写した一節を思い出した。事あるごとにこの言葉に救われてきた。
だれのものかご存知の方がいらっしゃれば教えてください。

ある夢が現実化する過程

押し寄せる感情の波をやさしく受け入れ
ひとつひとつの出来事に心を動かしても
奪われることはなく
つらぬく強い意志などとかいうものは
あまり考えないようにして
できる限りのやさしい視線で
遠くの方に静かな見通しを持ち続けること

本を読む会 - SRE サイトリライアビリティエンジニアリング #1

「本を読む会」と題して同僚とSRE本を読み進めています。このエントリは第1章を読んだメモです。ざっくりです。

  • 参加メンバ
    • missasanさん, syou6162さん, tomomii
  • 第1章担当
    • tomomii

ページ

SRE本を読む会の目的

  • SREの思想や考えを知る
  • GoogleのSREはどんな基準でものごとの判断や意思決定をおこない、開発実務をおこなっているのか理解する

冒頭でやったこと

本を読む会に求めることをそれぞれ共有しました。

  • SREが使うツール Mackerelをサービス開発・運営している。SREを支援したり仕事がやりやすくすることを提案するポジションという観点で自分に何ができるかを考えたい
  • インフラ技術や知見を勉強中。SREの考えを知ることで、サービスオーナーシップについて理解を深めたい
  • SREというポジションの魅力、技術領域の幅の広さを知った。組織やチーム開発の視点で学びが多そうだ
  • SREの思想や考えを知り、組織のあり方について考えたい

tomomii : 読み解きたいこと

  • SREの役割
  • SREの戦略
    • Hope is not strategy. "願望は戦略にあらず" →どゆこと？

読書メモ

1.1

  • 大規模かつ複雑なウェブシステムの歴史
    • システム管理者（シスアド）の役割
    • 開発と運用（DevとOps）の分断によるコストやデメリットに着目
      • Dev : サイトの成長に寄与
        • 新機能を開発し、ユーザーさんがそれを使っている様子を見てみたい
        • 自分でコードを書いて動くものを作る人
      • Ops : ユーザーさんが成長したサービスを安定的に適切な速度で障害発生なく運用し障害発生時の対処をする
        • すでに存在するものを組み合わせて（システムの癖やバグを理解しながら）安定的にシステムを運用する
  • 障害はどんなときに発生するの
    • システムになんらかの変更が生じたとき。人為的変更⇄システム変更、両方ある
      • 新機能や新設定をローンチ
      • 機能を追加したことで発生
      • 新しい種類のユーザトラフィックなど
  • Dev「好きなものを好きな時に邪魔なしにローンチしたいんジャー」 vs Ops「いったん順調に動いたシステムに変更を入れたくないんジャーー」
    • ↑ 対立的で病的なバトル

1.2

  • SREとは、ソフトウェアエンジニアに運用チームの設計を依頼した時に生じる（力を発揮する）エンジニア組織である
    • SRE is what happens when you ask a software engineer to design an operations team.
  • SREの業務領域
    • 50~60% : ソフトウェアエンジニア
    • 残り： + Unixシステム +システムネットワーク
  • SREチームを立ち上げてから
    • 運用チームが行なっていたことを自動化
    • SREは自動化やソフトウェアを開発を厭わない人を充てる
    • そしてSREチームとして、ソフトウエアエンジニアリングに注力することを求めた
  • どんな人がSREの適性にフィット?
    • 手作業のタスクに飽きる、自動化したい ≒ 運用に頼らない、システムで解決できるようにする
    • 自動化できるスキルセットを持っている ≒ 運用に頼らない、システムで解決できるようにする
    • ソフトウェア開発に適したアカデミックな知識経験 ≒プロダクト開発の効率化、生産性向上に貢献できる
  • SREチームをつくって見込める効果
    • 開発/運用の分断による機能不全を回避
    • 加えてプロダクトチームの停滞も改善。SREとプロダクト開発エンジニアを異動させることで相互トレーニングを実施。Reliability 向上の循環を促す組織構造をつくる
    • 結果として 分散システムの構築方法を学ぶ機会を醸成 > エンジニア全体が幅広い技術領域を扱える理想のすがたに
  • SREの採用難易度
    • 高
DevOps ? or SRE?
・DevOpsの定義はいまだに固まっていない
　・システムの設計と開発のフェーズに役割を持たせる
　・人手ではなく自動化を進める
　・運用タスクにエンジニアリングのpracticeとツールを適用
つまり DevOps ≒ SRE??
 DevOpsはSREの中核的な方針のいくつかを幅広い組織、管理の構造、個人に対して一般化
 SREをDevOpsに独特の拡張を加えたプラクティス

1.3

  • SREの信条
    • サービスの可用性、レイテンシ、パフォーマンス、効率性、変更管理、モニタリング、緊急対応、キャパシティプランニングに責任をもつ
      • ↑Ops の概念に近い

1.4

始まりの終わり

「願望は戦略にあらず」の意味が見えてきた気がする
  • SREはDevとOps 双方の「こうなればいいな」を実現するためのエンジニアではなさそうだ
  • SREのお仕事
    • サービス特性ごとの "Site Reliability"が何かを見極め、システム基盤に最適な設計を決めてソフトウェアエンジニアリングでウェブシステム基盤を開発する
      • だから'worked much closer with subset of devs' で 'more coding' が必要なんだな〜
        • fullset ⇄ subset

わかったこと

  • SREの役割
    • ウェブサイトの信頼性（スピード、落ちない、新機能開発しやすい等）を実現し維持する
    • 結果としてエンジニアの生産性向上と開発効率化に貢献
      • ＝ウェブサービスの成長とプロダクト開発エンジニアの生産性を担うエンジニア。ウェブシステム基盤全体のクオリティ責任者。かっこいい
  • SREの戦略
    • ウェブサイトの信頼性を維持する
    • 信頼性をどう担保するかはサービスによって異なりそうだ
    • システム基盤に必要な要素の優位性と優先度を決めてつくる
  • SREが生まれたきっかけ
    • Googleが思い切った判断をした
    • ウェブシステムの基盤開発に何を重視するかを新たに定義したのがすごい
      • DevでもOpsでもなく、SREのミッションはウェブサイトの Reliability. Reliabilityに必要なことはなんでもやる
      • Ops はなるべく自動化し、システムの課題はソフトウエアエンジニアリングで解決する
      • Dev と Ops の対立構造を脱却、ソフトウエアエンジニアリングを重視

感想

  • SRE = まるで航空機のパイロットのようだ (tomomii妄想)
    • 信頼性を第一義に考える強い使命感、入念な準備、緊密な連携、刻々と変化する状況への対応など、奥深い世界
    • 過去の知見と計器を頼りに変わりゆく外部環境をつどモニタリングしながら、最適な航路を進むべく判断を繰り返し、安全かつ最適な航路で目的地へ向かう
  • 凄腕な庭師にも見えてくる (tomomii妄想)
    • 京都の別荘群 碧雲荘や何有荘を預かる超スゴ腕庭師
    • 外部環境、土、植物、デザイン、設計、季節の移ろいなど数多な条件を知り尽くし、訪れる人たちを楽しませることと庭の整備運用を両立させて息の長い美しい庭をつくることができる
  • 参考資料にあげたLinkedInのSREが語るReliabilityのヒエラルキー構造は興味深い
Hierarchy of Reliability

SRE Hierarchy of Needs

1. Metrics and Monitoring
2. Reproducible Builds
3. Stable/Predictable Releases
4. More Communication
5. Dev Ownership (including testing)
6. Build a Team
  • 一人で黙々と読むのとは違い、複数メンバーかつ別のバックグラウンドを持つ方の視点をいただけて勉強になりました

ほか

  • Mackerelの役割
    • MackerelはSREヒエラルキーにおいて上位とされている Metrics and Monitoring, Capacity Planning そして Testing&Release Procedure (システムに異常がないか正常であるかそしてこのまま飛び続けて問題ないのか、修正するならどこか）のデータを蓄積し監視する
    • SREがシステムをみて判断する際に「なにをもって異常とみなすか、正常とみなすのか」をMonitoring してくれる

参考資料

www.youtube.com

SREcon16 - SRE at a Start-Up: Lessons from LinkedIn

INFRASTRUCTURE & OPERATIONS - How Google Does Planet-Scale Engineering for Planet-Scale Infra

このあと読みたい本と動画

戦略を決めるための道筋や方法論をおさらいしておきたい。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

第2章 Google - Site Reliability Engineering へつづく

監修：y_uukiさん