YAMAGUCHI::weblog

海水パンツとゴーグルで、巨万の富を築きました。カリブの怪物、フリーアルバイター瞳です。

SRE NEXT 2023でクロージングキーノートで登壇しました

はじめに

こんにちは、Google CloudでオブザーバビリティとSREの担当をしているものです。去る2023年9月29日、SRE NEXT 2023というSRE関するカンファレンスにて、僭越ながらクロージングキーノートスピーカーを拝命しましたため、その責務をまっとうして参りました。

sre-next.dev

「信頼性目標とシステムアーキテクチャー」

発表スライドと当日の録画へのリンクはこちらです。

speakerdeck.com

www.youtube.com

クロージングキーノートという貴重な機会をいただいたわけですが、自分の立場として参加者の方々に何を一番伝えたいか、何が求められているのかなど、依頼を頂いてから悩ましい時間が多くありました。SREというのはたくさんのプラクティスのまとまりですが、やはり自分が伝えたいことがあるとすればSLOに関わることだなと思い、セッションタイトルだけ思いついたので、細かな内容がまだなにも思いついていない状態で運営の方にお伝えしました。

詳細はセッションスライドと録画を見ていただくとして、この発表で伝えたかったことは

  • サービスレベル目標を決めると、自ずとシステムのアーキテクチャーや開発のプラットフォームに影響が及ぼされるということ
  • 信頼性目標にたどり着くためのアーキテクチャーは対話によって妥当な点を見出すしか無いこと

発表の中では確率を例にして検討を重ねていますが、こういった検討そのものが開発や運用のチーム全体で共通に認識されるべきもので、検討の末に必要になったもの費用も論理的に導かれることが伝われば幸いです。プラットフォームエンジニアリングという言葉もありますが、発表の中でも述べているように、ある程度以上の信頼性はプラットフォームがなければ達成できませんし、Four Keysも本来であればSLOを達成すべきプロセスの文脈で出てくるはずのものです。

このセッションをきっかけに、一人でも多くの方にSLOの有用性が伝われば幸いです。

こちらの書籍にも本セッションで話した内容が触れられていますので、ぜひご一読ください。

r9y.dev 盛り上げていきましょう!

自分のセッションの中で紹介した r9y.dev は「SREエンタープライズロードマップ」を著したSteve McGheeやJames Brookbankが始めたプロジェクトで、各信頼性目標に応じて必要になるテクノロジーを議論しながら作っているものですが、皆さんからのフィードバックやレポジトリへのプルリクエストを元に発展しているものです。ぜひdiscordに参加してコメントをいただけると嬉しいです。

discord.com

またオンラインで公開ディスカッションを行っているのですが、日本からの参加者が多くあると事前に分かればAPAC時間での開催もできると思うので、是非discordやGitHubのレポジトリで提案してください!

SRE NEXT 2023の熱気がすごかった

SRE NEXTへは初回の2020年の回から3回連続で登壇の機会をいただき、個人的には思い入れのあるカンファレンスの1つです。

sre-next.dev

sre-next.dev

特に日本でSREに関するトピックだけを扱った(SREをカンファレンス名に冠した)数百人規模のカンファレンスというのはSRE NEXTしかなく、その点で個人的にとても応援しているカンファレンスでした。そして今年はオンサイトイベントとして復活した回だったわけですが、セッションの内容が「SREのプラクティスを実践してきての学びや振り返り」に関するものが多く、明らかにコミュニティのSREに対する理解や実践度合いが進んできていると思いました。また会場の雰囲気も活気があり、これからが本当に楽しみなカンファレンスだなあと感じました。

自分はSREcon APACの20222023でProgramme Committeeに参加したのですが、SREcon APACのセッション内容と比較しても、SRE NEXTは実践的な内容が多く、日本のSREコミュニティの質の高さが伺えました。SREconの場合はグローバルサービスの運用に関する発表が多いですが、SRE NEXTは日本ローカルならではの小中規模の組織での実践の話が聞けるのが貴重だなと感じます。

個人的に好きだったもの

セッションに参加したりブースを回ったりして面白かったものを、Xに投稿されていた写真をお借りして振り返ろうと思います。

私が翻訳や監訳に関わった3冊(「SLO サービスレベル目標」「オブザーバビリティ・エンジニアリング」「SREの探求」)の途中率が高いので、読了率を上げる企画をなにかしたい!(アイデア募集中)

セッションの合間に流れるこの映像とかセッション開始時のティザー動画とか、めちゃくちゃかっこよく作られてて、ただ感心していました。

わざわざ広島からいらして運営にも参加してくださっていた @okash1n さんの「ワキヤコーヒー」さんのコーヒーは美味しかった!

オライリー・ジャパンさんのブースはありがたいことに私の翻訳、監訳に関わった書籍(上記の3冊に加えて「Go言語による並行処理」も)を販売してくださっていました。こういうところで自分の本を紹介できるのは嬉しい!

ホールウェイトラックも大いに盛り上がって、新しいイベントの企画とかその場で決まっちゃう感じがコミュニティの勢いを感じました!写真に写っている逆井さんにも登壇してもらうOpenTelemetryのイベントが今月半ばにあります!

opentelemetry.connpass.com

Topotalのインシデント管理ツールのWaroomのデモを見せてもらいました。オープンベータが出たときに触らせてもらったときから、すごく進化していてこれからどうなっていくのか楽しみです!

おわりに

また来年も開催されることを願っています。今年の後半は自分はだいぶSLOを中心にメタな登壇が多かったので、来年は少し技術を深ぼった内容の登壇にまた戻していきたいという気持ちになったカンファレンスでした。運営の皆様、お疲れ様でした!

関連リンク

togetter.com

冬キャンプのほうが好きな理由

はじめに

先日、友人家族とデイキャンプをしたんだけれども、まだ友人家族は宿泊するキャンプをしたことがなく、色々とハードルがないか調べているところだったそう。なにかを決めるときは色々な制約があるわけだけれども、様々な理由から自分は冬キャンプのほうが好きなので、理由とともにそれをお伝えしました。

せっかくなのでメモとして自分が冬キャンプのほうが好きな理由を説明していこうと思います。なお、前提として自分は東京在住で、冬キャンプは主に南関東道志村〜富士周辺、山梨県北杜市の南側などに行くことがほとんどです。

TL;DR

自分はおおよそこういった理由で冬キャンプのほうを好んでいます。

  • 虫が出ない
  • 日焼けしない
  • 暑くない
    • 熱中症の心配がない
    • お風呂に入らなくてもなんとかなる
    • 食べ物が腐らない
    • 冷たいものは冷たいまま飲める
    • 寝やすい
  • 人が少ない
  • 大気が安定していて天気が予想しやすい
  • 星が綺麗
  • おこもりキャンプがしやすい
  • 焚き火のしがいがある
    • 焚き付けの木を拾いやすい

冬キャンプが好きな理由

虫が出ない

自分は虫一般は好きなので、気がついたらテントの中にバッタやカマキリが居たりするのはむしろキャンプの醍醐味だと思ってているのですが、蚊やアブは嫌いです。刺されたら痒いを通り越して、アブなんかだとめちゃくちゃ腫れます。最悪です。あまり頻度は高くないですが、夏はムカデやスズメバチなんかも出てきます。「虫が苦手なのでキャンプをしたくない」という方がいう「虫」がどこまで含まれるのかは人によると思うのですが、昆虫好きでも蚊やアブに喜んで刺される人は相当マニアックな人だと思います。

害虫対策として

  • 長袖を着る
  • 虫除けスプレーをかける
  • 強力な蚊取り線香太巻き蚊取り線香やパワー森林香など)をいくつも焚く
  • ヤブ蚊バリアといったスプレー剤を地面に撒く
  • 虫取りUSBランタンを点ける
  • オイルランタンに虫除けパラフィンオイルを使う

などさまざまにありますが、100%防げるわけではありません。冬は害虫含め、虫全般はほぼ活動していないため、こういった懸念をする必要がありません。

日焼けしない

夏は暑さから半袖を着がちで、風通しのいいオープンタープの下などで過ごしがちとなります。日も長いため、日に当たる確率はかなり高くなります。日焼け止めを塗ったりはしますが、汗をかいたり、それを拭いたりするなかでどんどん取れてしまい、塗り忘れなどで日焼けをすることも多くあると思います。虫対策とあわせて、可能であれば長袖をを着るのが賢明でしょう。自分はこうした理由から夏は日差しを避けられる林間サイトを選びがちです。もちろん、その分虫は増えるのですが。

しかし冬であればそもそも防寒のため長袖を着ています。また寒さ対策のため、サイドやフロントの跳ね上げはするにしても、テントの中で過ごすことも多いため、日焼けを気にすることはありません。

暑くない

日本の夏は暑いです。特にここ10年は最高気温が35度を超えることも多く、ひどいときには40度近くにもなります。標高1000m近いキャンプ場でも日中は30度を超えることがざらにあります。*1熱中症の懸念がいつもあるので、標高の高い場所でかつ日陰が多い林間サイトや風が涼しい川沿いの涼しいキャンプ場でないと行きたくないと感じています。冬であれば当たり前ですが暑くはありません。寒くはありますが後述するように防寒対策で十分対応できます。

熱中症とまでいかなくとも、結構汗をかいたりするので、夜寝る前にお風呂に入りたくなります。高規格キャンプ場でお風呂やシャワーが併設されていたり、近くに温泉があるキャンプ場なら良いですが、そうでなければ汗拭きシートなどでお茶を濁して寝ます。場所によっては寝苦しい夜にもなります。日の出が早いので朝早くから気温が上がります。1泊で帰るとしても撤収する頃にはもう汗だくです。冬は汗をかくこともなく、自分だったらキャンプなら2日くらいだったらお風呂に入らなくてもいいかなあ、という感覚で過ごしています。また翌日に日中温泉に行くときも、冬の露天風呂など風情があって良いです(好みによる)。寝るときも装備があれば暖かい寝袋でぐっすりと眠れます。

夏は気温が高いので、外で食材を扱うときも注意が必要です。肉などは特に注意が必要で放っておけば腐ってしまいます。また夏の暑いときに限って飲みたいのは冷たい飲み物です。僕は自然の中で飲む冷たいビールは夏キャンプの醍醐味の一つだなと思うわけですが、一方でそれを実現するには保冷を頑張る必要があります。キャンプを続ける中で、2泊3日程度であれば前日の買い出しのみで冷たいビールを2日目夜まで維持するテクニックを獲得しましたが、やはり面倒です。食材も腐らせないようにテクニックを駆使したりします(例: そもそも食材自体を凍らせて持っていくなど)。しかし、冬はそんなことを気にしないでもそもそも気温が冷蔵庫なみの温度なので、特にビールの温度や食材の傷みなどは気にしないでも問題ありません。むしろ凍らせたくない食材をクーラーボックスに入れます。現代のテクノロジーでは冷やすよりも温めるほうが圧倒的に簡単なので、キャンプは気温が低いほうが何かと便利です。

人が少ない

キャンプは世間一般だと夏のアクティビティだと認識されているせいか人も少なく、冬はキャンプ場もオフシーズン価格になっていたりします。人気のキャンプ場も冬ならば予約が容易だったりします。人が多いキャンプ場、特にフリーサイトのキャンプ場だと、車を駐めるのも一苦労、テントの設置も限られたスペースで行わなければならないこともあったりします。また洗い場やトイレも混雑していたりします。人が少ない冬の時期では、そういった人の多さに起因するストレスはあまりありません。

大気が安定していて天気が予想しやすい

夏は気温が高いため雲が発達しやすく、近年ではゲリラ豪雨と呼ばれるような、突発的な雨も増えています。キャンプの懸念事項として挙げられやすいのは雨ですが(個人的には人が少なくなるのであえて雨キャンプに行くということもしますが)、キャンプに慣れてある程度対応できるならまだ良いですが、あまり準備もできておらず、また設営も不慣れなうちに大雨に降られてテントの浸水体験などをすると心が折れかねません。ここ数年はTC素材のテントも流行っていますが、雨に対してはTC素材は弱いため、悲惨な結果になる人もいます(給水して重さで最悪テントが潰れる)。また台風でそもそもキャンプの予定自体を諦めなければいけないというリスクもあります。設置や撤収の際の雨もスピードが問われ、慣れていないと荷物がずぶ濡れになるなど大変な思いをします。

その点冬は大気が安定していて、かなりの確率で予報通りになることが多いです。もちろん予想外の雨が降った場合の備えは持っては行きますが、概ね杞憂で終わることが多いです。また予想外に降られたとしても夏のような大雨になることはあまりなく、テントの中にいれば快適に過ごせます。

星が綺麗

これは夏冬関係なく、晴れていれば見える場所ではきれいに見えるわけですが、冬は乾燥しているため特に星が綺麗に見えます。星にあまり興味がない人であっても、少し山に近い明かりの少ないキャンプ場で夜にテントから出たときに、空一面に広がる星を見たときは思わずため息が出るのではないでしょうか。冬は夜の時間が長いためこうした星空を長く楽しめるのも良いですね。

おこもりキャンプがしやすい

夏はとにかく日光が強く気温も高いため、テントの中は蒸し暑くなってしまいます。これはベンチレーションを開けてサーキュレーターを回したとしてもどうにもなりません。夏キャンプの場合は寝る直前までオープンタープで過ごして、寝るときだけテントに入るということになります。私は一人で行くときはもはやそれに耐えられず、夏はハンモック泊やタープ泊をしています。(夏はこの装備になれるとその手軽さや涼しさから辞められなくなりましたが、それはまた別の話)

冬は逆に寒さを凌ぐために囲いがあるテントの中が快適空間になります。布一枚でも囲いがあるだけで随分違うものです。また最近はキャンプ用家電も充実しているので、ポータブル電源やモバイルバッテリー接続で電気毛布などを使うと、随分暖かくなります。自己責任で注意深く使う必要はありますが、灯油ストーブなどを点けると、換気用にベンチレーションを開けていても、ダウンなしで十分暖かく過ごせたりします。わざわざキャンプ場に行ってテントにこもるというのは矛盾しているように聞こえるかもしれませんが、テントの中で煮炊きをしてゆっくりと過ごすというのはそれはそれで楽しいものです。特に何かアクティビティをしたいわけではないけれど、自然に近いところでのんびりしたいオートキャンパーにはおすすめのスタイルです。

焚き火のしがいがある

焚き火をするという行為そのものはオフィス勤務の自分には非日常感があって、キャンプならではのアクティビティです。しかし夏は暑い。暑さに加えて焚き火の熱が来るとこれはもうたまりません。外で熾火や炭火で焼いた肉は格別に美味しいのですが、とはいえ暑い。暑いのです。

ところがこれが冬になると、焚き火も立派な暖房器具となります。スチール製のリフレクターで囲うと、防風できるだけでなく、輻射熱により焚き火の前は非常に暖かくなります。また薪も乾燥しているため、よく燃えます。寒い季節は、焚き火を見ながら暖かい飲み物を飲むという事自体で幸せを感じます。コーヒー、ココア、ホットワインウイスキーや焼酎のお湯割り。どれも想像しただけで過去のキャンプのリラックスした時間を思い出します。

またキャンプ場によってはサイト内に落ちている枯れ木を焚き木や薪にして良いのですが、冬はそういった枯れ枝や松ぼっくりがよく落ちていて、また乾燥もしているため、焚き火に困ることがありません。

夏キャンプのメリット

これまで夏キャンプが苦手だという話ばかり書いてきましたが、それでも夏にもキャンプをします。夏キャンプの好きなところも当然あります。

  • 装備が軽くて良い
    • 軽装で過ごせる
    • 凍死する心配がない
  • 川や海のアクティビティが楽しめる
  • 山が気持ちいい
  • テントがすぐに乾く

装備が軽くて良い

よっぽど標高の高い山にでも行かないかぎり、薄手の長袖(パーカーやウィンドブレーカー)を持っていれば、まず夜に寒くて寝られないということもなく、まして凍死する心配などをすることな無いでしょう。虫よけのためであっても必要な長袖は薄手で良く、また防寒対策等も必要ありません。寝心地さえ確保できれば寝られます。寝袋すらいらず、自分はブランケットだけで寝ることもよくあります。

大型のドームテントは使わずに、日中はタープの下で過ごし、寝るときだけ1.5人〜2人用テントで寝ます。特にソロキャンプのときはタープの下でフライシートを外して蚊帳代わりにインナーテントだけで寝ることもよくあります。また最近は蚊帳付きハンモックとタープだけの装備で行くこともよくあります。装備がとにかく軽く設営や撤収も10分程度で終わるので本当に快適です。

ウォーターアクティビティが楽しめる

キャンプにあわせてアウトドアアクティビティもするときは、水辺の活動ができるのが夏ならではです。単純に川や海に入って涼んでも良いですし、湖や海でSUPやパックラフトをするのも気持ちいいものです。特に日の出直後の人気が少ない時間帯に水辺を散歩するのは気持ちが良いものです。

山が気持ちいい

避暑に行く場合には標高が高い場所にあるキャンプ場に行くことが多く、そういうところでは東京では夜中でも30度を超えるようなところでも、林間サイトなどでは20度前後まで下がったりすることもあります。夜は静けさの中に風の香り、虫や鳥の声などが聞こえ、心地よい時間が流れます。また朝は涼しさと同時に霧や靄が立ち込めて、山の朝独特の雰囲気があり、そういった時間にホットサンドを食べたり、朝から炊いた白米を頬張ったりするのはなんともいえない満足感があります。

テントがすぐに乾く

たとえ夜に雨に降られても、サイトの水はけがよく、日がよく当たる場所であれば、撤収する頃にはテントが乾いていたりします。これは特に夏は日の出が早いので日光に当てて乾かす時間も長く取れるのが良いです。

冬キャンプのデメリット

最初の方では冬キャンプが好きな理由としてメリットをたくさん挙げましたが、当然デメリットもあります。デメリットとは言っていますが、準備をすれば解決できることもあったりしますし、またそれを克服するのが楽しみでもあったりするところではあります。

  • 装備がかさばる
    • 準備をしないと凍死しかねない
  • CB缶の燃焼力が下がる
  • 液体が凍る
  • テントが乾きづらい
  • 開いているキャンプ場が少なくなる
  • 風が強い

装備がかさばる

夏キャンプの逆です。当然寒いので防寒対策をしっかりしないとただただひたすら寒さと戦うだけのつらい時間を過ごすことになります。服装は上下防寒着、できれば靴もスキー場に行くつもりで厚い靴下やブーツを履くのが望ましいです。寝具もしっかりしたマットや寝袋、暖房器具(湯たんぽ、ホッカイロ、電気毛布、ストーブ等々)が必要になってきます。マットは安いクローズドセルマットでも重ねると断熱性能は足し算できるので、たくさん持っていけばなんとかなります。

CB缶の燃焼力が下がる

キャンプで調理をする際はバーナーを使うことが多いですが、私は主にオートキャンプをしているため、バーナーはCB缶のみで過ごしています。しかしCB缶の主成分である液化ブタンは沸点が-0.5度なので、100均で売っているCB缶だと火力が弱かったりつかなかったりすることがあります。

そのため冬キャンプに行くときは、少し高級なCB缶を使っています。OD缶用バーナーやアルコールストーブも万が一のため携行していますが、最低気温-10度くらいまでのキャンプでは普通のCB缶とこういった少し高めなCB缶のみで過ごせています。

こういった高いCB缶には液化イソブタンや液化プロパンが入っていて、沸点が低め(それぞれ -11.7度、-42度)なので、オートキャンプに行くような場所では問題なく過ごせています。OD缶はそもそも高山でも使えるように中身が液化イソブタン、液化プロパンがメインになってくるため、こういった心配はほぼありません。(安いOD缶でも液化イソブタンと液化ブタンの混合で、CB缶のように液化ブタンのみということはありません)

液体が凍る

メリットで触れていた外気温の低さですが、気をつけないと凍ってしまいます。うっかり凍らせてはいけない容器に液体が入っていると、朝起きたときに容器が変形したり割れてしまっているということがあります。また容器が壊れるまで行かなくても、朝起きて水を使いたいのに凍ってしまっていて使えないということもあります。凍らせたくないものは寝る前にクーラーボックス等に入れておくなど注意が必要です。

開いているキャンプ場が少なくなる

人が少なくなるのはいいのですが、冬は閑散期になるため、冬期は運営しないというキャンプ場もしばしばあります。特に標高が高いキャンプ場は、キャンプが好きな人であっても、よっぽどしっかり準備しないと凍死のリスクがあるために閉鎖しているという場合もあります。またキャンプ場自体は開いていても、たどり着くまでの山道が凍結や積雪で通行困難になっていることもしばしばあります。スキー場に行くときと同様、スタッドレスタイヤやチェーンなどの装備はしっかり整えていく必要があります。

風が強い

小学校や中学校の理科でも習う通り、冬は西高東低の気圧配置になることで偏西風が強化されて強い風が吹きます。(冬から春かけてが強い)特に冬は気温も低く、空気中の水蒸気量も減るため同じ風速でも風を強く感じます。キャンプをしていて、雨よりも怖いのは風です。風速5m以上を超えると、テントやタープが煽られてペグが勢いよく抜けて人や車に当たったり、ポールが折れてテントが建てられなくなったり、焚き火の熾が飛んでいくなど、危険です。これは定常的な風速ではなく、瞬間最大風速で起きえるリスクなので、キャンプ場の立地にもよりますが、設営時には特に気をつける必要があります。

ゆるキャン△でも取り上げられたふもとっぱらキャンプ場は遮るものがないだだっ広いフリーサイトで、冬は通称「テントの墓場」と言われています。その凄まじさの例として次の動画をご覧ください。


www.youtube.com

とはいえ、いまは天気予報も発達していて、風速予報なども結構正確に出ていたりするので、事前に調べておくことでできる対策もあります。

おわりに

以上はいま装備がすべてある状態で考えたときに手間やコストを考えると、自分は冬キャンプが好きです、という記事でした。もちろん装備を揃えるにはそれなりに費用がかかりますし、また収納するにも場所を取ります。このあたりは趣味への投資という点と、家族の理解などがあるので一概にどちらが良いと言えるものではないですし、どの季節もキャンプは楽しいと思うので、興味がある人は是非一緒に行きましょう!

散々「冬が良い」と書いてきておいてなんですが、キャンプのベストシーズンは晩秋だと思います!

*1:オートキャンプで行くような場所では標高が100m高くなるごとにおよそ0.6度気温が下がりますが、それでも1000mで6度程度までしか違いがありません。

「SLO サービスレベル目標」という本が出版されました #slobook

はじめに

こんにちは、Google Cloudのオブザーバビリティ担当者です。このたび私が翻訳ならびに監修として関わった「SLO サービスレベル目標」という本がオライリー・ジャパン社より出版されました。本日より書店ならびに各社オンラインストアでご購入いただけます。

電子書籍版についてはオライリー・ジャパンのサイトよりePub、PDFの各種フォーマットにてご購入いただけます。

www.oreilly.co.jp

SLOがなぜ重要なのか

まず本書の意義について解説する前に、サービスレベル目標(Service Level Objective; SLO)がなぜ重要なのかについて改めてお伝えしたいと思います。

サイトリライアビリティエンジニアリング(SRE)において、その手法の名称にもあるように、「ユーザーの信頼性」というのは、その原理に根ざす重要な考え方です。システム運営に関わる人間および会計のリソースは有限であるため、サービスの品質もどこかで妥協しなければいけません。しかしその妥協がユーザーがシステムに期待する品質*1未満ではユーザーはサービスを利用してくれなくなってしまいます。そのためユーザーの満足度との相関が強い指標(サービスレベル指標)を発見し、その目標値(サービスレベル目標)を決める、というのがサービスレベル目標の考え方です。この目標は内部的なものであり、ユーザーとの契約ではないので、SLAと違い何度でも自由に見直し、より適切な値を探していくことになります*2

これは、システム運用の観点から見たビジネス的に重要な指標にもなり得るもので、SREというものが広く認知される以前から、データ駆動型経営をされている企業では名前こそ違えど、この観点から目標値を決めて運用してきたところもあるでしょう*3。SREではこれらの概念に対してSLI、SLO、さらにエラーバジェットやバーンレートといった名称と定義を与えて、さらにそれを継続的に運用していくという枠組みを作ったことに価値があると思います。一方で、こうした概念がSREとともになければならないかというとそんなことはありません。肝心なのは「自分たちが行っていることがSREかどうか」ではなく「自分たちのサービスがユーザーを満足させているのか」どうかであり、その文脈においてSLOという概念は各ビジネス指標のKPIと同様にいかなるビジネスにおいても考慮されるべきであるはずです。特にサービスの収益がシステムに依存している度合いが強ければ強いほど、このSLOという指標はビジネスにインパクトを与えているはずです。

2020年代において、たいていのビジネスはITシステムに依存していますから、このSLOという概念は会社組織の中で役職問わず理解されるべきものであると、私は考えています。「SLOをもっと使っていきましょう」という話に関しては次の文章でもう少し掘り下げて書きましたので、ご興味あればあわせてご一読ください。

zenn.dev

「SLO サービスレベル目標」はどのような本か

昨日SLO本出版イベントを開催いただきまして、書籍の内容もお話しました。お時間ある方はこちらもご覧ください。

www.youtube.com

本書はAlex Hidalgoが主著者として執筆し、また多くの共著者の寄稿を編集した "Implementing Service Level Objectives" という書籍の日本語訳版です。原著は2020年8月に出版されました。

本書は、同じくオライリー・ジャパンより出版されているSRE関連書籍のシリーズを補完する書籍だと思います。Google SREシリーズや「SREの探求」がSREの各種プラクティスを幅広くカバーしている総論であるのに対して、本書はタイトルにもあるとおり、サービスレベル目標(SLO)の実装と導入のみに焦点を当てて、その概念の説明から実装方法、さらに背景となる統計や確率の基礎知識、SLOに基づく運用を根付かせるための方法論や文化の構築など、SLOに関する各論を掘り下げて解説しています。

またその意味では、やはり私が翻訳に関わった書籍「オブザーバビリティ・エンジニアリング」にも近いですが、こちらはインシデントの解決に関連したオブザーバビリティの技術要件などに多くの焦点があたっている一方で、「SLO サービスレベル目標」はより前段階の開発と運用の判断を決定する部分に焦点を当てています。

SREを導入しようとしている、あるいはSREの導入を始めたが実践に苦労しているという人々と会話すると、やはり最も難しいと言われるのが、SLIの発見とSLOの設定です。そこから更にエラーバジェットを管理して、エラーバジェットのバーンレートを元にしたアラートで運用を行うレベルまでできているという組織はまだまだ多くありません。この理由の一つとしては、SLOという概念が難しい、ということではなく、その仕組みは単純だけれども、実際に機能させようとすると巷に手引きが少なく、各々が手探りで行っている部分が多いからだと思います。先の節でも書いたように、SLOはそれ単独でも十分に存在しうる重要な概念であるにも関わらず、です。また他にも改善を継続的に行うことに慣れるまでに時間がかかるということもあるかもしれません。

そんな中、私が本書が出版されたという知らせを目にしたとき、「Go言語による並行処理」を初めて読んだとき以上に興奮しました。本書の目次と内容を大まかに読んで、その興奮は本書は絶対に日本語でも出版されるべき書籍であるという確信へと変わりました。SREの実践において、最も重要だと思われるSLOに基づく運用を行うための手引きとして、これほどまとまっている資料は2023年現在、本書以外ありません。SRE本を読んだり、多くの企業がSREを導入しているという情報を耳にして、SREに興味を持ってSLOの導入を始めようと思っている方々、またSLOの導入から次の一歩を踏み出したいと思っている方々には必携の一冊であると思います。本書はSRE本を読んだことがなくても通して読めるようにできていますので、SREのプラクティスのすべてを実践するわけでなくても、非常に有益な内容となっています。また、先にも述べたようにSLO自体はSREとは離れて、単独で実践しうるものです。変化の早い時代において、ビジネス指標の1つとしてSLOを活用するためにも、有意義な一冊となっています。

本書は3部構成となっています。第1部はSLOの開発です。SLI、SLO、エラーバジェットといった概念を一から説明しています。初めてこれらの概念に触れる方は必ず第1部の章は通して読んでください。もしSRE本等でとこれらの概念をすでに理解している人であれば読み飛ばせるかもしれませんが、そのような場合でも念の為第1部は通して読まれることをお勧めします。特にSLOやエラーバジェットの計算に関する具体例を見ることで、自分の理解が合っているかを確認しながら振り返りができます。

第2部はSLOの実装です。第2部は第1部の理論を実際に導入する上で必要なプロセスに触れています。SLOを導入することへの各部署からの同意の獲得、SLOを支えるデータベースの仕組み、アラートの設計方法、SLIやSLOの計算のための数学的基礎知識、SLIとして使える指標、具体例を通したSLO設計の流れの確認、など、より実践的な内容が数多く紹介されています。特に9章は数学や統計の基礎知識を前提としていて、一瞥しただけで拒否反応が出てしまう人もいるかもしれませんが、安心してください。9章でも説明されているように、すべてがわからなくてもまったく問題ありません。個人的にはこの章は付録Bと同様に付録にしても良かったのではないかと思います。しかし、SLOの定義を厳密に行なおうと思えば、より細かな定義ができる、ということだけでも感じていただけたらと思います。

第3部はSLOに基づいた運用手法が実際に回り始めた後、それを維持し持続するために必要な内容が多く紹介されています。ここに書かれている内容は第1部と第2部を読み、実践を進めていく中でより理解が深まることでしょう。現在すでにSLOに基づいた運用を行っている方々には、非常に親しみのある内容になっていると思います。社内でより広くSLOを普及させるためのヒントになるような情報が多くあります。

関連書籍との関係性について

「SRE サイトリライアビリティエンジニアリング」と「サイトリライアビリティワークブック」

SREに関心を寄せる多くの方々がお持ちであろう書籍が上記の2冊です。前者は網羅的である反面、個々のSREのプラクティスに関する説明は個別のケースの説明にとどまるようなものであったように思われます。後者は書籍名が「ワークブック」とあるように、演習形式で代表的なプラクティスを少し掘り下げるもので、実際にSLOに関しては第2章〜第5章で解説されていますが、様々な場面でSLOを設定するための詳細、というよりは、SLOを活用するための一連の流れを体験するための入門という趣が強いです。

その観点で、「SLO サービスレベル目標」はSLOを中心として、理論的な側面、実践的な側面、文化的な側面など、SLOの導入と運用に関連するあらゆるトピックを網羅的に扱っています。実際に主著者であるAlexは、上記2冊のSLO関連の章の著者でもあり、「SLO サービスレベル目標」はそのテーマを掘り下げるために別途執筆されたものでした。

「オブザーバビリティ・エンジニアリング」

こちらは今年1月末に出版されたばかりの書籍ですが、こちらは書籍のタイトル通り「オブザーバビリティ」を自システム内に備えるための書籍です。本書の第12章と第13章においてSLOとの関連性を解説していますが、これはオブザーバビリティからの観点での解説です。こちらがオブザーバビリティをシステムに備えるための実装に関する解説を行っているのに対して、「SLO サービスレベル目標」ではシステムが計装すべきテレメトリーシグナルの決定に影響を与えるSLOの設定や、その可視化やそれに基づいたアラート設定に関する解説をしています。

また「SLO サービスレベル目標」が、どちらかと言うとユーザーの信頼性を維持するための施策(すなわち、インシデントが起きる前の施策)に重点を置いているのに対して、「オブザーバビリティ・エンジニアリング」では、インシデントも含めて、必要なときにシステム内部の必要なテレメトリーデータを分析できることを主眼としています。

したがって「オブザーバビリティ・エンジニアリング」と「SLO サービスレベル目標」はかなり相互補完的な書籍であると考えています。

「入門 監視」

「入門 監視」の原著 "Practical Monitoring" は2017年11月に発行された書籍です。本書は、まだSREがそこまで広く普及していなかった時期に、従来のシステム監視の視点から見た、現代的な監視に関して著した良書だと思います。本書では直接はSLOという言葉を使って解説はしていませんが、関連する話題はたくさん出てきています。

先にも述べましたが、SLOというのはSREを実践している人だけのものではありません。「入門 監視」では「ビジネスKPI」というビジネス側の目標値を監視する話がありますが、現代のサービスにおいてはシステム側のKPIもビジネスに十分影響を及ぼしていると思います。両者でしっかりと目標値を持った監視ができれば、より充実したシステム運用ができると思います。その観点で、本書と「SLO サービスレベル目標」を読むと、従来のシステム監視を行っているシステムにおいてもSLOが十分に有用であることが理解いただけると思います。

「入門 監視」の発刊当初の私の書評に関してはこちらにあります。 ymotongpoo.hatenablog.com

謝辞

本書のまえがきでも触れましたが、あらためて編集者の編集者のオライリージャパンの髙恵子さんに感謝いたします。そもそも本書の翻訳の企画は私から髙さんへの持ち込みで、当初は別企画が走ろうとしていたところを無理を言ってこちらに変えさせていただきました。また今回は当初は監訳のみという予定だったのですが、翻訳の品質に納得が行かなかったことやプロセスに問題があると感じ、私からはかなり要望を出す結果となりましたが、できる限りのことをしていただきました。諸々とストレートに意見したりと、髙さんには苦労をおかけしたことも多々ありました。また思わぬ予定変更でスケジュールがずれたりとトラブルもあり、結果2021年2月から始まった企画が、2年半近くかかりましたが、その分思い出深い企画となりました。*4 またpyspaの方々を始めとするオンラインコミュニティの皆様には、翻訳修正に苦労する中、多くの励ましをいただきました。一人でも黙々と作業を行う中でも、チャットであってもねぎらいの言葉をかけてもらえるだけで慰めとなりました。みなさま本当にありがとうございました。

おわりに

本書にも書かれている通り、本書の内容は1つのモデルでしかありません。本書を読めばすべてが解決する銀の弾丸ではありませんが、なにもない場所から始めるよりも遥かに優れた出発点になることは間違いないでしょう。本書のいたるところで繰り返し述べているように、本書を元に、組織内で多くの議論を交わしながら、SLOの導入を行う企業が少しでも増えることを願っています。

また本書に関するイベントを7/25にForkwellさんに開催いただきます。オンライン開催ですので、お時間あればご参加ください。

forkwell.connpass.com

*1:ここはさらに注意して考える必要があって、ユーザーの期待値にも幅があり、中には非常に厳しい要求をする人もいます。自分たちのビジネスがユーザーに価値を提供するために必要な品質、と考えるほうが良いかもしれません。

*2:もちろんSLOを公開しても構いません。実際にどの程度のサービスレベルを提供しようと考えているかの透明性を高めることになります。

*3:SREの語源にもなったような信頼性工学、あるいは安全工学に関連する領域では、たとえば工場における生産効率等に関する多くの指標が提示されています。

*4:この紆余曲折に関しては、要望があればどこかに記録を残そうと思います。

2022年版のState of DevOps Reportの日本語訳が公開されました

はじめに

こんにちは、Google CloudでオブザーバビリティとSREの担当をしているものです。毎年公開されると多くの方に参照いただいているState of DevOps Reportの最新版である2022年版が、日本語を含む10ヶ国語に翻訳されました。こちらのページで言語設定を日本語に設定いただいた上でPDFを申請すると日本語版がダウンロード出来ます。

cloud.google.com

これまでもすでに英語版が広く紹介されていたと思いますが、改めて日本語版が出たことで、より多くの方々におすすめできるようになったと思います。(次のスクリーンショットはfour keysに加えて、5番目の指標として信頼性が加わったことを解説しているページ)

State of DevOps Reportとは

あらためて、State of DevOps Report(以下、SODR)とはGoogle Cloudの一組織であるDORA(DevOps Research and Assessment)が2014年より行っている、DevOpsの業界動向に関する年次調査レポートです。DORAは書籍『Accelerate』(日本語訳版は『LeanとDevOpsの科学』というタイトルで出版されています)の著者陣が中心となって設立された調査機関で、2018年にGoogle Cloudの一部となりました。それ以降も、ベンダーに中立な調査機関として、継続して調査を行っています。

SODRは多くのDevOps系の記事やプレゼンテーションで参照されているのでもしかしたらどこかで目にしたことがあるかもしれません。(たとえば次の @t_wada さんのスライドのp.18以降から紹介されています。)

speakerdeck.com

上の『LeanとDevOpsの科学』は非常に有名なのでよく参照されていますがSODRはそこからのトレンドの変化を追っていくのに非常に役立つ資料となっています。まだ上の書籍しか読んだことのない方は、ぜひSODRも読んでみてください。上にありますように2022年版は日本語版が出ましたので、それを眺めるだけでも面白いかと思います。

2023年版向けの調査が始まっています

SODRが成立しているのは多くの企業の方々に調査に参加いただいているからこそです。

goo.gle

毎年多くの企業に参加いただいた結果、年次の追跡調査が可能となり、結果トレンドの変化などがさまざまに分かってきました。一方で、これまで英語のみで調査を行い、調査結果としてのSODRも英語版のみしかなかったためどうしても英語圏に偏った調査となっていました。(下図はSODR 2022のp.63より抜粋。日本からの参加者は全体の1%でした。)

今年の調査もすでに開始していますが、今年は調査の多言語化にも取り組んで、近々日本語でも調査が可能となります。*1多くの国からの調査が集まることで、各地域でのトレンドなどが見えてくることと思います。(追記 2023.06.02 日本語版のサーベイが公開されましたのでリンクを挿し換えました)

昨今もDevOps、SRE、Platform Engineeringなど、さまざまなキーワードが飛び交っています。しかし、その実態として、業界全体の各組織でどのような取り組みがなされているのでしょうか。それを明らかにしていこうという取り組みがSODRです。少しお時間かかる調査ではありますが、ぜひご協力ください!よろしくお願いします。

*1:公開され次第追って紹介します

「オブザーバビリティ・エンジニアリング」という本が出版されました #o11yeng

はじめに

こんにちは、Cloud Operations担当者です。このたび私が翻訳として関わった「オブザーバビリティ・エンジニアリング」という本がオライリー・ジャパン社より出版されました。本日より書店ならびに各社オンラインストアでご購入いただけます。

www.ohmsha.co.jp

電子書籍版についてはオライリー・ジャパンのサイトよりePub、PDFの各種フォーマットにてご購入いただけます。

www.oreilly.co.jp

また上記書籍情報ページに質問は報告を行うための連絡先も記載されておりますので、なにかありましたらそちらよりお問い合わせください。

TL;DR

「オブザーバビリティ・エンジニアリング」はオブザーバビリティの概念を理解し、それを実際にシステムに備えるために必要な技術要件を知り、実践につなげるための書籍です。オブザーバビリティを実践いる方やこれからオブザーバビリティを活用していく方には必携の書籍になると思います。ぜひご一読ください。

「オブザーバビリティ・エンジニアリング」のおすすめの読み方

本書は350ページ程度の中型本で、技術書としてはちょうどよいボリュームだと思います。したがって、オブザーバビリティに関して包括的に理解を深めたいという方であれば頭から通して読み進めていただければと思います。本書は「オブザーバビリティ」と呼ばれるシステムの性質に関して、その技術的な要件や具体的な実装方法、導入の際の文化的側面などを扱った書籍です。そのため、オブザーバビリティの大局観が得られずなにか参照したい方、これからオブザーバビリティを導入していくための考慮事項を把握したい方、オブザーバビリティの技術要件を理解することで既存のシステム監視との差異を理解したい方におすすめです。

本書を読むにあたって、関連書籍として同様にオライリー・ジャパンから出版されている「入門 監視」をご覧いただけると、オブザーバビリティと監視の関連についてより深い理解が得られると思います。また「SRE サイトリライアビリティエンジニアリング」「サイトリライアビリティワークブック」などのサービスレベル目標やアラートの設定に関する章も、本書のテーマと大きく関連しているので、SREの推進としてオブザーバビリティの実践や導入をされている方は、そちらも参照いただくのが良いと思います。

いわゆるSRE本はSREをテーマに横断的にプラクティスを紹介しているのに対し、本書はオブザーバビリティをテーマに概念的な話から具体的な実装の話までを一気通貫で紹介しているので、併読することでオブザーバビリティがSREの中でどこに位置しているのか、何を可能にするのかの理解が明確になると思います。

一点、私のあとがきにも書きましたが、本書はHoneycomb.ioというオブザーバビリティSaaS企業のエンジニア3名によって著されているので、その点に留意して読み進める必要があります。本書の具体例がどうしても彼らの製品の機能や実装による説明になっていので、その背景にある技術や思想を常に意識しながら読みすすめると、皆様が利用しているツールやシステムにおいてどのように適用できるか、何が達成されているかの理解が進むかと思います。

出版に至るまでの話

本書はCharity Majors、Liz Fong-jones、George Mirandaによって著された、 "Observability Engineering" の日本語訳です。

本書が出版されたのは2022年6月だったのですが、本書はEarly Releaseの対象になっていたのと、著者の一人であるLiz Fong-Jonesが元々Googleで同じチームでの同僚だったこともあり、出版以前に最初の数章が公開されてからすぐに読み始めていました。本書が解説しようとしている内容は、SREがだいぶ普及してきた現在において、サービスレベル目標をもとにした運用をする上で切っても切り離せないオブザーバビリティの獲得を行う方法であり、正式版の出版をかねてより期待していました。実際に正式版が出版され、改めてその内容は「オブザーバビリティ」の定義を解説し、本来の監視(モニタリング)と技術的にどのように異なる要件が必要なのかを解説した素晴らしい書籍であると感じました。「オブザーバビリティ」という用語が本来の意味合いから離れて、監視系ツールのマーケティング用語として濫用され、ただ「監視」という用語の置き換えとして用いられるケースが散見される中で、利用者側がその用語の意味を正しく理解するということは非常に重要であると考えています。当たり前ではありますが、そもそも別の言葉が導入されたということは概念として異なるからです。

こういった背景から、日々コミュニティで親しく、また「Java開発者のための関数プログラミング」「Go言語による並行処理」での編集としてお世話になった、オライリー・ジャパンの瀧澤さんに本書を日本語化する意義を紹介したところ、2022年7月半ばには早速企画にしていただき、そのまま翻訳の流れとなりました。また同様にいくつかのコミュニティでかねてよりオブザーバビリティやOpenTelemetryに関する情報を共有している大谷さん(以後、かっちゃん @katzchang)も翻訳に興味があるとのことだったので、半分ずつ担当して共訳することとなりました。

前述の通り、かっちゃんとは以前からオブザーバビリティに関して意識合わせがだいぶされていたこともあり、共訳の作業は大変スムーズでした。私自身が共訳をするのが初めてだったこともあって、訳語の統一などの点で難しさを感じた点もありましたが、自分の担当箇所の初校分に関しては9月中には終わらせることが出来ました。ただ、その後本業がだいぶ立て込んでしまい、見直しの時間があまり取れなかったので、レビュワーの方々にはだいぶ負担をおかけしてしまいました。

謝辞

訳者あとがきにおいても掲載いたしましたが、本業の合間を縫って、年末のお忙しい中、短い時間にもかかわらず有意義なレビューを数多くくださったレビュワーの皆様に感謝致します。

レビュワーの皆様(五十音順)

オライリー・ジャパン

  • 瀧澤昭広さん(@turky

レビュワーの皆様にはエンジニアとしての観点から多くのコメントを頂き、また解釈が不明瞭な部分に関しては、より明瞭になるように対案をいただくなど、非常に有益なコメントを頂きました。中でも何名かには多大なレビューを頂きました。瀬尾さんには、レビューが少なくなりがちな後半からレビューをいただくなど、訳者としてありがたかったです。松浦さんは「入門 監視」を始め多くの翻訳をされていることもあり、訳に関して良い対案をいただきました。馬場さんには、文章として説明が甘くなって部分(原文に原因があるものも多かったのですが)の的確な指摘をいただきました。若山さんには細かな解釈に関して指摘を数多くいただきました。

瀧澤さんに、Sphinxを使った執筆環境を用意いただいたことで、私は大変執筆しやすかったです。「Go言語による並行処理」を翻訳したころから、更にパワーアップして、瀧澤さん側でSphinxが生成するXMLからInDesignへの流し込みを自動化するスクリプトを作成されていたことで、依頼してから1日程度で組版された原稿をいただけるというのは、レビューを行う際に非常に有益でした。実際に執筆をされたことがある方は実感されると思うのですが、原稿のレビューを行う際に、フォーマット(テキストファイル、PDF、紙など)が異なるだけで見え方がまったく異なります。様々なフォーマットでの確認を手早く数多く行えるということは、ソフトウェアのレビューと同様、非常に有用です。ラムダノートの鹿野さんもそうでしたが、編集担当者がポストプロダクションの領域も担当されていることの心強さを感じました。

またかっちゃんとは本書の翻訳に関して、そもそもの本の立ち位置やその価値の認識、背景技術の理解など、息があっていたので、チャットで大きな反対意見でぶつかって議論になることはなく、ツーカーで作業を進めてこれたのはとても気持ちのいい体験でした。翻訳作業はこれまで割と孤独に行っていたので、息のあった共訳者がいる頼もしさを感じました。また機会があったら一緒にやりたいです。

あらためて、みなさまありがとうございました。

おわりに

手前味噌にはなってしまいますが、私が今現在で「SREおよびオブザーバビリティに関して読むべきN冊」という書籍を挙げるとするならば、確実にそのリストの上位に入るべき一冊だと考えています。ぜひ多くの方のお手にとっていただき、日本においてもオブザーバビリティに関する議論がより活発になることを願っております。

参照