YAMAGUCHI::weblog

噛み付き地蔵に憧れて、この神の世界にやってきました。マドンナみたいな男の子、コッペです。

スペインに行ってきた(2回目)

はじめに

こんにちは、Google CloudでオブザーバビリティやSREを担当しているエンジニアです。この記事はpyspa Advent Calendar 2023の6日目の記事です。昨日はしろうさんの「2023に有った無なこと」でした。

今年は本当に公私ともに疲れたので、11/19-27の日程でバルセロナに家族旅行をしてきました。そのときに気づいたこととか感想を書いてみます。

旅程

日程 アクティビティ
11/19 NRT→AMS→BCR
11/20 散歩、フラメンコライブ
11/21 サンパウ病院&サグラダ・ファミリア
11/22 モンセラット
11/23 市内バスツアー、外食
11/24 バルセロナ水族館、外食
11/25 バルセロナ動物園、外食
11/26-27 BCR→AMS→NRT

スペイン旅行と言いつつ、全日程バルセロナのみの旅行です。

気付きと感想

スペインは7年前に一度行っていて今回が2回めでしたが、前回は大人だけでの旅行で、今回は子どももいる旅行だったので勝手がだいぶ違いました。特に夜に気軽に遊びに行けないのは、バルセロナの旅行においてはだいぶ勝手が変わります。1度行ってる場所だからそんなに新しい気付きは無いだろうと思っていたら、前回と同行者も異なれば、自分のスペイン語力も違うこともあって、多くの気付きがありました。

シベリア上空通れないのきつすぎる

ロシアのウクライナ侵攻開始以降でヨーロッパに行くのが初めてでしたが、事前にわかっていたとはいえ13時間超のフライトはなかなか堪えました。シベリア上空が通れないので、行きは北極圏ルート、帰りは中国上空ルートで帰ってきました。

しかし、北極圏ルートなんて冷戦時代の過去の話と思っていたので、まさかこうしてそのルートを使う羽目になるとは思ってもみませんでした。昔と違ってアンカレジで給油しないで済むようになっただけマシとは言えますが、体が大きいのでエコノミーシートに13時間はなかなかにハードでした。またいろいろと国同士のいざこざはありますが、中国も上空を通してくれていることは助かりました。ここを通れないとなるとユーラシア大陸上空は中東経由とかにするしか無くなります。

ja.flightaware.com

ja.flightaware.com

またスペインは旅行当時の2023年11月には日本からの直行便が存在せず、今回はアムステルダムでの乗り換えにしましたが、乗継便の待ち時間も含めて片道20時間くらいかかったので、移動で相当体力持っていかれました。多少親バカになりますが、うちの子どもは長時間フライトにも関わらず移動中ぐずりもせず、iPadや機内エンターテインメントなどで静かに過ごしてくれて、本当に助かりました。これで13時間未満の直行便であれば余裕を持って家族旅行に行けるという自信にもなりました。

スペイン語で畳み掛けられる

新型コロナ禍に入ってからDuolingoでスペイン語の勉強を始めたんですが、3年位続けているといよいよ実際にスペイン語圏に行って試してみたいという気持ちになり、今回のバルセロナ旅行は個人的に修学旅行の意味も込めて行ってきました。毎日少しずつでも続けているだけあって、読み書きに関してはかなり分かるようになっていて、街頭の看板や文章、お店のメニューなんかはそのまま理解できることが多かったです。

また店員との挨拶や注文なんかのやり取りでは、こちらがスペイン語で話す分には普通に理解してもらえました。一方で、聞き取りはだいぶ難しいと感じました。こちらがゆっくりでもスペイン語を話すと、相手は普通のスピードでスペイン語で返してくるため、それを理解するのに苦労することがしばしばありました。「ゆっくり話してほしい」といっても結局0.95倍速くらいの速度で返されることが何度かあったため、ゆっくり話してもらうことは早々に諦めました。

英語のリスニングがまだ苦手で、全然聞き取れなかった頃の感覚を思い出して新鮮でしたが、最終的にスペイン語で意思疎通できなかったときは英語でやり取りできる事が多いので、安心感はだいぶ違いました。英語は国際語とはいえ、前回来たときの学びのとおりやはりスペイン語が話せるに越したことはないなと実感しました。

カタルーニャ語優先だけどスペイン語は全然使える

バルセロナ含むカタルーニャ自治州は、近年でも独立に関して住民投票が行われたりと、歴史的経緯から長らく中央政府との確執が強い地域です*1。独自の文化も持っていて、地域の言語であるカタルーニャ語を地域公用語としています。スペインの国家としての公用語スペイン語ではあるので、公共施設などではカタルーニャ語スペイン語、英語の3カ国語が併記してあるのがよく見かけられます。

これは動物園内の禁煙に関する注意書き。右側に太字で大きくカタルーニャ語、左側に太字でスペイン語、細字で英語が書いてあります。

これは水族館内の案内。上からカタルーニャ語スペイン語、英語。

これは駅の路線案内。左から太字で大きくカタルーニャ語、普通のウェイトでスペイン語、斜体で英語

そんなバルセロナですが「カタルーニャ語を話さなければ疎まれて無視される」というようなことはまったくなく、むしろスペイン語で話すのであれば歓迎されるようなことばかりでした。自治州として確執はあるものの、外国人旅行者がその国の言語を話そうとする姿勢を示すだけでだいぶ歓迎されているように思います。

バイクが多い

バルセロナ市街に長期滞在して気がついたのですが、市内を走っているバイクが非常に多かったです。

特にビッグスクーターを多く見かけました*2。目にしたもので多かったのはヤマハのXMAXスズキのBurgmanでした。警察も白バイにBMWビッグスクーターを採用したりしているくらいでした。

バイクが多いので、当然バイク駐輪場も充実しています。こちらはバルセロナ市街中心地のカタルーニャ広場の端にあるバイク駐輪場です。

他にも町中にバイク駐輪場がいたるところに設置されていました。

タクシーが多い

良くバルセロナの観光ガイドには「タクシーが多いから普通に手を挙げて捕まえましょう」みたいなことが書いてありますが、実際に観光にいってみて改めて意識してみると、どこを歩いていてもタクシーを見かけました。

この黄色と黒のペイントがしてあって、車両の上にTAXIという光るサインと緑ランプがあり、どこかに登録番号が書いてあるタクシーは正規タクシーなので安心して乗れます。料金は自治州が公表していて、記載のある何段階かのレートが適用されます。

料金 時間 初乗り km毎
T-1 平日昼間(8:00-20:00) €2.30 €1.21
T-2 休日終日 or 平日夜(20:00-8:00) €2.30 €1.45

他にあとT-3とT-4という料金体系がありますが、前者はタクシーアプリ(後述)経由での固定料金、後者はクルーズ船に乗るときの固定料金なので、流しで乗るときは上の2つの料金体系だけ気にしていれば大丈夫なようです。(空港など入るのに別料金が追加されることもあります)

タクシースタンドもあって、このような黄色でギザギザが書いてあるところで「TAXI」という看板がある場所で手を挙げて待っていればタクシーが来てくれます。

なお、Uberバルセロナでは使えませんが、上記のように流しのタクシーがたくさん走ってるのであまり困ることはありません。それでも自分の場合は、復路の飛行機が朝6時で、朝3時半には出なければならず、かつコンドの管理会社もタクシーの予約の手伝いはできないとのことだったので、仕方なくタクシー配車アプリを使いました。

www.free-now.com

FREE NOWというアプリが一番使われているとのことだったので、そちらを使ったのですが、最初だけSMS認証をしなければならず、使っていた海外SIMがSMSに対応していなかったので、その設定のためだけに日本のSIMを一瞬だけ使いました。日本でアクティベートしてから行くことをオススメします。使い方はUberとかと変わらず簡単で、かつちゃんと事前に予約した通りの時間に来てくれたので良かったです。料金も事前に提示してくれていたので安心でした。(おそらく上のT-3に該当する料金)

朝3時半でもちょっと移動して待っていれば捕まえられそうなくらいにはタクシーが走っていたので、一人で旅行している場合にはあまり必要ないと思います。

公共のゴミ箱が多い

上のタクシーが並んでる写真の手前部分に黒いゴミ箱があると思うんですが、あんなゴミ箱が街中にありました。町中でコーヒー飲んだりチュロス食べたあとのゴミなんかをそこに捨てられて便利でした。

そしてそれとは別にめちゃくちゃでかい分別ゴミ箱がところどころにあって「このでかいゴミ箱はどういう扱いなんだ...?」と疑問に思っていました。家庭ごみなんかもここに捨てに来るそうです。満杯になるとゴミ収集車がいい感じに集めてくれるそうです。

スーパーのレンチン食材も美味しい

「スペインはご飯が美味しい」というのはもはや説明の必要のないほどの周知の事実ですが、スーパーで売っているレンチンの食材も日本に引けを取らないほど美味しかったです。これはある日のもう疲れ切ってしまってコンドの中で食べることにした夕食の食卓ですが、ムール貝イカスミパエリア、スパニッシュオムレツ、ズッキーニスープのいずれもただ買ってきたものをレンジなりコンロで温めただけです。どれも満足でした。地元ビールはあまり好みではありませんでした。

スーパーといえば、生ハムにかける本場の熱意を感じました。

自転車専用道はあるにはある

日本では自転車は原則車道ということになって、急場しのぎで車線の端に自転車マークや走行帯を表す青い印を描いただけのところがほとんどですが、バルセロナ市街では一応専用道らしきものが確保されている場所がチラホラありました。

とはいえすべての道路がこうなっているわけではなく、ない場合は日本と同じように車道の端を走れという感じでした。日本と比較して思ったのは自転車に乗る人がアグレッシブで、連結バスの横を自転車がすり抜けようとしたけれど、車幅の狭さのせいでバスの窓にぶつかってる人が一人二人ではありませんでした。

観光バスは初手で乗っておくと便利

子どもが時差ボケで眠い中歩くのは嫌だからバスに乗りたいというので、到着3日目は一日市内観光バスに乗りました。バルセロナ市内観光をしてくれる観光バスは2種類あって、紫のほうがバルセロナ市が運営しているもの、赤いのが民営です。公共機関にお金を落としたほうがいいと思ったので自分たちは市が運営するものに乗りましたが、民営に乗っても大差はないと思います。

3日目で乗ることにしましたが、一番最初にこれに乗っておいたほうが良かったなと乗ってから思いました。理由としては「バルセロナ市街の全容を楽に大まかに知れる」「主要観光地のクーポンがもらえる」からです。

バルセロナは南東にある海岸から北西の山際の高級住宅街まで南北に高低差があるんですが、それを効率よく回るのはなかなか難しいです。特に南側の地区はあまり便が良くないので、さーっと流して主要な施設を様子だけ眺めたいという場合には観光バスは便利だなと思いました。

またバスに乗る際にもらえるクーポンを使うと主要な観光地がまあまあ割引される(家族全員分だとお茶するくらいは割り引かれる)ので、観光地に多く行く場合にはおすすめです。(オンラインで予約する場合に使えるクーポンコードも書いてある)

おわりに

まだ気付きはあったような気もしますが、気がついたらまた追記します。

スペインは今回が2回目でしたが、前回も今回もとても楽しく過ごせました。特に今回はスペイン語をある程度使えるようになってから行ったのでより楽しめました。やはり語学は楽しい。長時間フライトは大変ではありますが、また機会があれば、次はマドリードやマラガなんかに行ってみたいです。明日は渋川さんです。

参照

*1:サッカーでもレアル・マドリードFCバルセロナの対戦であるエル・クラシコ中央政府カタルーニャ地方の代理戦争的な意味合いを持っていることも有名。

*2:もちろん、普通のネイキッドやツアラーなども見かけましたが、スクーターの数が多かったです

「実践プロパティベーステスト」という本が出版されました #pbtbook

はじめに

こんにちは、Google Cloudのオブザーバビリティ/SRE担当者です。このたび私が翻訳しました「実践プロパティベーステスト PropErとErlang/Elixirではじめよう」という書籍がラムダノート社より去る11月1日に出版されました。書店ならびに各社オンラインストアでご購入いただけます。

実践プロパティベーステスト ― PropErとErlang/Elixirではじめようwww.lambdanote.com

電子書籍についてはラムダノート社のECサイトよりご購入いただけます。

実践プロパティベーステスト ― PropErとErlang/Elixirではじめよう(電子書籍のみ)www.lambdanote.com

「実践プロパティベーステスト」はどのような本か

本書の内容に関しては、すでにラムダノート社の書籍紹介ページで十分に説明されているので、まずはそちらをご一読ください。

www.lambdanote.com

プロパティベーステスト(以下、PBT)は関数型プログラミング言語界隈で発展してきた経緯もあり、ユニットテストやファジングと比較するとあまり浸透していないのが現状です。また使い始めようと思うとプロパティを書くところで難しさを覚え、独学でマスターするのはなかなかにハードルが高いものです。実際に私もその部分がネックで、PBTを学びたいと思いつつ、何度か挫折をしていました。そんな中、本書を初めてオンライン版で読んだときに、相変わらずFredのユーモアある解説に感心しつつ、この本であれば習得できるかもしれないと思いました。

本書は、まずPBTとは何か、それ自体の解説から始まり、PBTの根幹である「プロパティ」についての解説、そして探索をうまく行うために欠かせない「ジェネレーター」のカスタマイズ方法、失敗したテストを理解しやすくするための「収縮」の解説、さらにはステートフルなシステムをテスト対象にできる「ステートフルPBT」の解説、とPBTを一通り学ぶために必要な知識を網羅しています。解説に使うサンプルコードやその結果の特性はErlang/Elixirという言語やPropErというPBTフレームワークに依存する部分もありますが、他の言語のPBTフレームワークも大なり小なり同様の機能をサポートしていますので、読み替えを行うことでPBTより深く学べることでしょう。

そもそもPBT自体があまり脚光を浴びることはありませんでした。しかし計算資源をより活用して、ステートレスPBTでユニットテストを強化することはもちろん、ステートフルPBTでe2eテストを強化すること、それこそがソフトウェアエンジニアリングではないでしょうか。もちろん、PBTの場合、プロパティやジェネレーターの実装や、テストを走らせる上での時間的なコストはあります。これは私が普段触れているオブザーバビリティの領域でも同様です。網羅的かつ効率的に探索を行うことで、仕様策定時や実装時に気が付かなかった問題を発見し、その原因を突き止められる確率が高まることの価値は、ますます高まっています。そういった文脈で、本書は皆さんの道具箱に道具を1つどころか、引き出しを1つ追加してくれる、そんな一冊です。

「実践プロパティベーステスト」が出版されるまで

本書はFred Hebertによる "Property-Based Testing with PropEr, Erlang, and Elixir" という書籍の日本語訳版です。原著は2019年1月に出版されました。

以前私は同じくFred Hebertが著した "Learn you some Erlang for great good!" の日本語訳「すごいErlang ゆかいに学ぼう!」(以下、すごいE本)という本の翻訳を行いました。

すごいE本の詳細に関しては出版時にエントリーを書きましたのでご参照ください。

ymotongpoo.hatenablog.com

すごいE本ではErlangの基礎から始まり、OTPの発展的な使用方法まで網羅していました。もちろん、その中にはテストに関する章もあり、たとえばEUnitの関する基本的なところから、静的解析(Dialyzer)まで行うのですが、それ以外のより発展的な検証については一切触れられていませんでした。Erlangのエコシステムを知りつつ、他の言語で主に開発を行っていた身としては、Erlangの達人たちが使いこなしていたプロパティベーステスト(PropEr)に関する情報がもっと出てきてほしいなあと思っていました。

そんな折、2017年の半ばにFredがまたPropErに関するテキストをウェブで公開し始めました!

propertesting.com

そこにはいままで知りたいと思っていたプロパティベーステストをPropErで実施するための考え方を、すごいE本と同様に一から紹介してくれるものでした。しかも前回とは違い、Creative Commonsではなく、All rights reservedとのこと。これは本が出るのではないか?と思いウェブ版が完成した2018年後半のある日Fredに連絡してみると出版予定とのこと。そこで、すごいE本の編集を担当し、その出版後、オーム社から独立されラムダノートを設立された鹿野さんにダメ元で連絡してみました。

「Fredが書いたプロパティベースベストに関する良書があるんですが、翻訳できませんか」

ラムダノートでこの本を出版する場合、編集作業等で割かれる時間や在庫を考えると、この本はリスクの高いものであることは明らかでした。使用言語はErlang/Elixirという、一応知られてはいる言語であるものの、まだメインストリームとは言えない言語で、さらにテーマは発展的内容のプロパティベーステスト。それだけ見ればニッチ極まりない本です。

しかし、このプロパティベーステストという手法そのものは、計算機の力を活用した素晴らしいテスト手法で、原著出版当時からメジャー言語向けフレームワークも一応存在していました。この本によって需要を起こせるかもしれない、という期待も鹿野さんは理解してくださり、プロジェクトが始まりました。翻訳権の獲得から始まり、原稿用レポジトリの用意までが整ったのは2019年4月。そこからコツコツと翻訳を続けて半分程度まで終わっていたのですが、2020年3月に新型コロナウイルスの蔓延とともに仕事や家庭の状況も一変し、なし崩し的に一時翻訳が中断してしまいました。

その後、2022年5月にようやく生活が落ち着いたこともあり、また並行して走っていた他の翻訳プロジェクトが区切りが付いたため、一気呵成に取り組み2022年6月には一度翻訳を終わらせました。しかし、今度はここから訳文自体の日本語をより自然にする編集作業が始まりました。一度スケジュールが崩れてしまったため、鹿野さんには別の大きなお仕事の合間に編集を行ってもらいつつ、自分は細かな修正をするという作業が続き、とりあえず識者レビューをいただける形までになったのが2022年11月でした。識者レビューを経て、もう一度巻頭から編集し直して、2度めの識者レビューを頂いたのが今年の9月。そこから細かな修正が行われ、10月半ばに無事に校了したという流れでした。

私はこれまでオライリー・ジャパンでの翻訳でお二人の担当に付いていただき、オーム社とラムダノートでは鹿野さん、高尾さんに編集いただいたわけですが、やはり皆さん様々に特徴があると感じました。ラムダノートのお二人の編集は、編集者として徹底して日本語を整えてくださる印象がありました。実際に自分でも読み返してみると、編集前後で日本語として読みやすさが向上していると感じました。

気がつけばきっかけとなったウェブサイトの公開から6年も経っているわけですが、しかしながらその技術的な内容はまったく陳腐化していません。これはPBTがそれだけ強力な概念であるということの証左ではないでしょうか。早く出版できなかったのはひとえに自分の至らなさではあるわけですが、ようやく出版できていまは肩の荷が降りた気持ちです。

他言語におけるプロパティベーステストについて

本書はErlang/Elixirを中心にPBTの解説をしているわけですが、その考え方は汎用的なもので、他のプログラミング言語でも写経しながら進められると思います。以下が自分が知っていたり、ぱっと調べた限りでの他の言語でのPBTフレームワーク一覧です。(網羅しているわけではありません。)

もちろんフレームワークによって対応の度合いは異なるので、これらを使って本書をErlang/Elixirとまったく同様に進められるわけではありません。たとえばPythonのHypothesisではジェネレーターは意図してランダム値になるように振っていて、PropErのように意図して偏らせるようなことができません*1。また上には列挙していませんがGoのgopterというフレームワークではステートレスPBTしか実現できません*2

謝辞

書籍中の謝辞でも書いていますが、あらためて、本書は次のみなさまのご協力なしには出版はありえませんでした。特にErlang/Elixirに関しては趣味レベルの私とは異なり、業務でErlangとPBTを使われていた経験がある、また今まさに現役でErlang/Elixirを書いている皆様方からいただけたレビューは本書の質を最後に押し上げてくださるものでした。あらためて感謝いたします。

レビュアーのみなさま(五十音順)

  • 上西康太さん(@kuenishi)
  • 大田健さん(@sile)
  • 大原常徳さん(@ohr486)
  • 篠原俊一さん(@shino)
  • 宮崎達矢さん(@ta_ta_ta_miya)

ラムダノートのお二方

  • 鹿野桂一郎さん
  • 高尾智絵さん

いただいたレビュー(随時更新)

*1:無理やりに実現することは可能ですが、フレームワーク作者はその方針ではない

*2:gopterは開発が3年ほど停止しているので挙げませんでした

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:この紆余曲折に関しては、要望があればどこかに記録を残そうと思います。