自分の時間を過ごす

休日のよしなしごとを書く。
朝から澄んだ青空が眩しく昼から気温が上昇した。ぽかぽか陽気に春を感じる。
テレビ台や本棚上に被った埃を拭いて、花屋で見つけたミモザの花を飾り (こんな素敵な花で400円) ベランダに出るとくしゃみが止まらない。やらなくちゃいけないことがあるが、花粉の日は家と図書館で過ごすに限る。
雑誌の一節が目にとまり手元のノートに書き留めた。アインシュタインの「Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world.」を想起する。

想像する、その行為自体も楽しいけれど、想像するためにまず、知ろうとすることがいい。「想像」と「知識」は表裏一体なのだと思う。
たくさん知り、たくさん想像することで、更に知りたくなる。更に知ると、想像はもっと広がる。それを繰り返すうち、自分とは違う考えも、違う立場にいる人のことも、少し理解できるかもしれない。遠くの声に耳を傾け、遠くの出来事に目を凝らす。


翌日は、昨日と一転して雲の低い雨空となった。春先は花粉に加えて気温のアップダウンが激しく天候の揺れ戻しが何度も訪れる。凪いだ地に着くには、険しい難所を経験する必要があるのだ。まるで人生のようだなぁ、そんなことをぼわぼわと考える。

すごい勢いで流れていくたくさんの情報や人々の思いはどれも強く輝いて見える。のんびりで取捨選択が追いつかず、いちいち感化されては自分を変えたくなったり手当たり次第に新しい本を読む。そんなことを幾度となく繰り返して、ついにはくたくたに疲れ、ふと思うのだ。私の時間は？
もっと余白を、もっとぼやぼやしたり一つの言葉の意味を味わったり一冊の本や身近なひとたちとのお喋りに時間をかけるのが好みじゃなかったか。

自分にとって、植物に水をやるのと好きな言葉を反芻するのは似ている。苔庭にいる何種もの苔たちや熟練のパティシエが作るケーキを眺めていると組織やシステムをイメージする。著者や物語の登場人物や目の前のひとが大切にしている世界の一片を理解できたような気がすると、海の底で宝物を見つけたぞおみたいな気分になる。
「Few are those who see with their own eyes and feel with their own hearts. 自分自身の目で見て、自分自身の心で感じる人は、とても少ない」これもアインシュタインの言葉だ。こんなひとときが好きなのだった。

目先のことを考えて時間を過ごしてきたように思う。間違いをせずまともに（間違えるしちっともまともじゃないが）効率的で合理的でなければいけない。苦手なのに、できないのに、そんなことばかりを意識してきた。だけれども、そういった価値観だけで生きるのはしんどいと思うことが増えた。もっと遠くからの視点を持ちたい。

自分の時間を過ごしているように思えるひとは、いつもずっと遠くの方を見ているせいか穏やかで静かに見える。知らなかったことが知れたり、できなかったことができたり、思いもよらなかった越境ができたり、ひとつの体験や経験から得られる学び気づきや喜びに満ちている。

たまに道に迷いながら自分の地図を作っていく冒険者のように思える。

2019年

あけましておめでとうございます。
今年も穏やかに新年を迎えることができました。

昨年お世話になったみなさま、ありがとうございました。

2018年

振り返りです。2018年 - Words fly away, the written letter remains.
地図なしで迷宮を進むような心持ちで1年を過ごしていたように思います。
自分の知見や考えたことを文章にして、他者に伝えるといった活動は特にできませんでした反省。しかし言葉にする機会には何度か恵まれて、それにより自分の見通しがこれまでより定まったことは複利です。このことは2019年の抱負で少し触れます。

業務繁忙に託けて、優秀な同僚ややさしい人たちに助けてもらいながら、定常運行で日々の仕事と時間を過ごしていきました。しかし周りが優秀でやさしいがために余計に、自分はこのままでいいのか？「一日生きることは、一歩進むことでありたい/湯川秀樹博士」自覚的にそう生きている？が頭をもたげてきました。1年を通してこの思いは定期的に湧いています。

花粉の飛ぶ時期は図書館で過ごし、緑が芽吹くとおいしいお店をめぐり苔を見にお出かけしました。季節とともに暮らせる京都は本当に素敵な場所です。晩秋の澄んだ時期は特にそう感じます。上品な古家具みたいな侘び寂びがあります。

5月末に書いた ある夢が現実化する過程 - Words fly away, the written letter remains. このエントリに対して、いくつかのうれしい反響を個別に寄せていただきました。「長い目で、自分の道を生きよ」事あるごとにわたしを支えてくれている一節です。
この頃に同僚有志が集ってSRE本の輪読会をスタートしました。エンジニアではない自分のレベルに合わせて理解を示してくださる同僚に感謝です。SRE本のファンで、SREのスタンスは真似したいと思っているので、これからも定期的に読むでしょう。年明けから輪読会は再開予定です。

夏は酷暑でしんどかった。仕事はしっかりすること大前提で、暑さのあまり無で毎日を過ごしつつ、自分を取り戻すことを考えていたように思います。
Culture At Netflix | Netflix Jobs を何度も読み、これを自分に落とし込むイメージで、今までの業務経験と考えをまとめた "My Culture" 的なスライドを手元で作ったりしました。
周りがスピード感を増して変化するなか、自分だけ立ち止まっているように感じることが増えました。深い森に迷い込んだ気分でした。
冬。森を歩き続けながら、長い目で物事を見るように気をつけていました。うっかり自分をなくしてしまいがちでした。時に他者と自分の境界が曖昧になり、情報や出来事の波にひどく疲れてしまって、意識的にそういった環境から距離を置くようになりました。自分の感受性やばいとなって、でもどうしたらいいかわからず、ひょいと日帰りで尾道に出かけてたくさんの細道を歩きました。坂と階段と文学の街は、落ち着きと表情がありました。

2018年後半の惑いは自分の人生にとって必要な時間だと思えます。季節の移ろいや酷暑と同じだと思って、多少不安になっても、おいしいものを食べたりごろごろと自分の時間を楽しむことに貪欲でいます。
「一つのステップを挑戦して、考えて、感じて、楽しんでください」そう送ってくれた友人に感謝しています。落ち着いてゆっくりと話ができるひとと会うようにしたい。

2019年

業務ではこれまで手付かずだったことに手を入れてやりきりたい。今までと同様に、以下は私が何をしようとも変わらない自分の軸だと思って過ごします。

自分の感情に耳を傾ける余裕が生まれたり、落ち着いた気持ちを取り戻せたり、本当にしたいことに気づけたり、新しくて豊かな価値を作ったり考えたり楽しむ力が湧いてくる。そういった場や組織づくりをサポートしたい。
http://tomomii.hatenablog.com/entry/2017/01/01/021238

私的なことでは、ある分野の社会人大学院を目指したいと考え始めています。組織とひとと事業の関係や自分の関わりについてお話する機会があり、そのことで自分がそれらへの興味関心が強いことを再認識しました。過去に師が自分に伝えてくれた内容の理解がやっと深まってきたことも大きなきっかけです。入試がありますね、大変だ。
ほとんど趣味の英語学習として howard rheingold's | tools for thought を手元で訳しています。今年中に形にできるといいな。

世の中には「すぐにわかるもの」と「すぐにはわからないもの」2種類があるとされています。すぐにわかるものは、言葉にしやすく通り過ぎてしまう。だけど、すぐにわからないものは（例えば宇宙とかひとのように）何度も考えたり眺めたり行き来したりするうちに、じわじわと解りだして、何かと繋がったり別の価値を生むことがあります。後になって、自分が見ていたものは断片だったことに気づきます。そういったすぐにわかりづらいものに目を凝らし、枠組みや仕組みやお作法を知って考えてみたい。

それから、2019年の展望 - ゆううきブログ で記されている松尾芭蕉の言葉「古人の跡を求めず 古人の求めたるところを求めよ」が琴線に触れ、漫画「バーテンダー」を読んでみました。
私にロールモデルはまだいません。だけど、たくさんの碩学や師が成し遂げている（遂げてきた）ことを理解し、そのためにどんな振る舞いや考え方をしてきたのかについて自分なりに解釈して実行することは、オリジナルでクリエイティブなことだと思えます。行動指針にしたい。

最後に、怪我で手足の自由を失った車椅子の詩画作家 星野富弘さんの言葉が心に触れたので記します。口で筆を咥え、紙の上に美しい花と言葉を生み出されています。花を好む母のコレクション画集から抜粋。

ひとは空に向かって寝る。永遠を見つめよ と言っているのでしょうか
たおれても、その時もしひまだったら、しばらく空をながめ、また起きあがるのさ

わたしの言動に誤りや不愉快や稚拙な点があれば、それは間違いだ違うよ、と忌憚のない指摘をいただきたいです。リアルやインターネットで関わりのある方々はどうかご協力くださいませ。

元気においしいものがたべたい！
本年もどうぞよろしくお願いいたします。

思考の向き

日常的におこなっている思考や想像(妄想)の種類について書く。
ひとつめ、過去の体験や出来事について、なんで? なんでなんでなんで? を繰り返す類のもの。振り返りはここに含まれる。
次に、自分と離れたものごとについて思考徘徊する。時事ニュースや他者の言動や読み聞きしたことに対して脳内議論をして自分を確認する。他には、自分の現状についてああでもないこうでもないと思考する。ぐるぐる考えたり悩んだりする。
最後に、未来についてのあらぬ妄想。自由である。

せっかくなら、未来や前に向かう思考や想像を増やしたい。思考や想像は、なにかを知ろうとしたりわかることに繋がる。
この文章を書きながら「明日」「楽しそうなこと」2点にフォーカスして試したところ、明日の楽しそうな自分について調べたり知ろうとすることがわかった。

  • 例 : 明日の楽しそうな自分 = 明日おいしいものをたべる自分
    • 明日おいしいものがたべたい > なにがたべたい ＞どこの > 場所やお店を調べ始める > たべたいものとお店を決めはじめる > 自分が明日になにをたべたいのかわかる > たべる

自分がなりたいこと、ありたい姿、ほしいもの、いきたい場所、会いたいひと、やりたいこと、習得したいわざ等々、未来の自分をたくさん思考想像する。するとたくさんのことが知りたくなる。知った中のいくつかは実現に向けて選択をスタートすることがあるだろう。なんだか思考したり想像すること自体が楽しくなってきませんか。
かつて上司が「イメージしないことは実現しませんよ」と言われた。アインシュタインの言葉を思いだす。

  • Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world.
  • The more I learn, the more I realize I don’t know. The more I realize I don’t know, the more I want to learn.

思考想像と知識が正の循環を繰り返すうちに、いつしかこれまでの自分が知り得なかった領域の扉を開けているかもしれない。異なる価値観や今まで知らなかったけど好きになりそうなこと、未知の世界を知ったり理解できるようになるかもしれない。
目先のことだけじゃなく、すこし遠くの自分に向けて目を凝らしていこう。インターネットの恩恵に与り情報が簡単に得られ、なんとなく世界が狭く感じたりわかったような気になってしまう。そんな今だからこそ、見えない未来や向こう側の領域について意識的に思考し想像したい。

本を読む会 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