ぷちダイアリー（たぶん本家）

きょうは朝から親の手術のため病院へ。

家族の立ち会いがいるらしい。

…かなり大手術なので所要時間が長い。

本人は全身麻酔なのでいいけど、ワイはタイムトラベルできんので、数時間ひたすら待つことになる。

本でも読むか…と思って持ってきた。

病院に向かうために乗ってる電車、よく考えたら普段会社に行く電車より1本早いわ。

そら混むわ。

というオライリーの本。

病院で読んでいるのでメモ。

・SREとDevOpsは似てるようで違う。SREはサービスの信頼性に対するアプローチであり、DevOpsは開発と運用、つまりデリバリーに対するアプローチである。

・SREはシステムに対してオーナーシップを感じている。問題や理解を追求するために、システムの端から端まで、またはそれ以外のどこにでも行く。「私のコードではないので、私の問題ではない」とはならない。サービスに問題があれば、それはSREにとっての問題である。

ごろうさんみたいだね！

・SREはもともとジェネラリストである傾向がある。

ごろうさんのことだね！（得意分野はあれども、特化はしていない　ストレージも電気通信もセキュリティもビジネスもカバーするのがごろうさん）

・SREはトイルとそれが引き起こすアレルギー反応に怒りを覚える。

ごろうさんのことだね！（トイルとは、決まりきった本来自動化可能（だがしていない）でかつ非生産的な作業のこと）

・システムの成功は、不注意による欠陥と同じくらいシステムの信頼性を脅かす可能性がある。つまり、マーケティングがうまく行き顧客が爆増した場合の期待や負荷がそれにあたる。

・SRE活動をはじめたてのときは小さく成功したら、他の人たちにそのことを大喜びで報告しよう。こちらが仕事を可視化しなければ、周りも可視化しない。

・SREにはコーディングの知識、計算機科学の知識、統計学の知識、ストーリーテリングの能力、あるいはNALSD（SREワークブックに記載あり）やレジリエンス工学（ごろうさんでいうと鉄道保安か）などの知識が必要。それぞれどのくらい必要かは、目指すSREによって異なる。

・Hyrumの法則（ハイラムの法則）

SRE本に出てくる概念。ハイラムはGoogle社の人名。「たとえばAPIで品質保証があるパラメーターと品質保証がないパラメーターがある場合、いかに事前に品質保証がないと伝えていようとも、観測可能な値をすべて依存して使う者が現れてくる」というような内容。

……あれ？読み終えちゃった。後半かっ飛ばしたけど。

奈良は一日中晴れか曇りだったけど、

夜にふと空を見ると、東の空がやたらとピカピカしていた。それはもうパチンコ屋のように。

花火ではないし……雷にしては音がしないし激しいし……

…と思ったら、松阪・伊勢のほうでえげつない雷雨だったらしい。

雷だったんだ……。