ポストモーテムにおける根本原因分析

技術

SRE Advent Calendar 2018、僭越ながら3日目を担当させていただきます、@kabaomeです。

勢いでカレンダーに登録しましたが、私は明示的にSREというポジションではなく、一アプリケーションエンジニアです。 半年くらい前にSRE本*1を読み、「こういうのやっていくゾ☆」と思い立って、社内で勝手にいろいろやっています。いまのところ怒られていません。

ポストモーテム、その中でもっとも重要であり難しい（と思っている）根本原因分析について、個人的見解を書いてみます。

TL;DR

  • ポストモーテムやその根幹である根本原因分析の情報あんまない
  • 根本原因分析の結論は「客観的」「単純」「制御可能」であるべき
  • 根本原因分析はスキルだと思います、がんばっていきましょう

ポストモーテム

まずはポストモーテムについて簡単にご紹介します。 SREの皆様におかれましては常識だと思いますので、読み飛ばしてください。

ポストモーテムとは、もともとは医学の世界で、「検死」を意味する英単語です。 検死とは、「死体について医学的に検査し、死因や死亡の状況について判断を下す」仕事を指します*2。翻って、プロジェクトマネジメントの世界においても、プロジェクトの結果、主に失敗ケースに対して振り返りを実施し、その原因や再発防止策を策定する営みとして広く知られています。

私を含むソフトウェアエンジニアに広くこの言葉が知られたのは、やはりGoogleのSREによる取り組みであり、それを流布したSRE本にあると思います。以後、ポストモーテムを（本来の用語ではなく狭義の）言葉として用います。

ポストモーテムとよく似た文脈で、いわゆる「インシデント報告書」がよく出てきます。 こちらも一般的な定義はありませんが、「サービスに障害が発生し、顧客が不利益を被った場合に、顧客に対する説明として提出する文書」を指します。インシデント報告書とポストモーテムはその目的・存在意義から明確に異なっています。

目的 想定読者
インシデント報告書 インシデントの報告・情報共有・謝罪 顧客、上司などのレポートライン
ポストモーテム インシデントからの学び・サービス改善 開発者

ポストモーテムにおいて、インシデントは学びの対象であり、サービスの信頼性を向上させるための材料です。その視点で振り返り、アクションプランをたて、またチーム内に共有します。

ポストモーテムそのものについては、SRE本及びWorkbookを読んでいただければ良いのですが、いかんせんGoogle以外での実例を聞いたことがほとんどありません。SRE的改善！自動化！みたいなのはカッコよくて対外的にもオープンにしやすい一方で、ポストモーテムはインシデントに関する情報でセンシティブなため、あまり外に出さない力学が働くのではないかと邪推しています。

そこで今回は、SRE本のポストモーテム章をさらに焦点を絞って、「根本原因分析」について、これまでやってきた経験をもとに書いてみます。

根本原因分析

Root cause analysis (RCA) is a method of problem solving used for identifying the root causes of faults or problems.

この定義からわかるように、根本原因分析はあくまで「問題の解決」を目的としており、そのために原因を特定する手法です。

ドラッカーが再三説いたように、ソフトウェアの運用にとどまらずビジネスなど人間の知的活動のあらゆる局面において、物事を進める上で最も重要視されるべきものの1つが「正しい問いをすること」です。人間は「いかに正解を出すか」に陥りがちですが、真に重要なのはその前段、解こうとしている問題が正しいかに頭をつかうべきです。間違った問いに対する正しい答えが最悪、というのはよく言われる話です。

インシデントの分析においても同様で、間違った原因に対する正しいアクションは最悪です。余計な運用手順を増やしたり、象徴的にはドキュメントが無限に膨れ上がっていきます。そこでRCAを行うわけですが、これが激ムズです。

根本原因に到達するための問い

よりよい学び、ひいてはサービスの信頼性向上のために、根本原因分析の結論に対する心構えを、問いの形で3つ挙げてみます。それは、「客観的か？」「単純か？」「制御可能か？」です。

以下では例としてデプロイ作業時のインシデントに関するRCAの結論に対し、何が良くないのか、どうすればいいのかを考えてみます。

  • 作業：あるWebサービスに新機能を追加してデプロイする
  • 事故：デプロイ手順にある、ロードバランサを切り離す作業を実施しなかった
  • 結果：デプロイ中にアクセスした複数のユーザがエラー画面を経験した

客観的か？

事実を客観的に書くように努めるべきです。 人間が絡むあらゆる営みで、主観を完全に排除することは不可能です。先のインシデント例において、客観性を欠いた原因として、例えば以下です。

  • 原因：デプロイ手順をしっかり確認していなかった

これは、デプロイ作業を行った担当者が自らRCAとポストモーテムの記述を行ったときに出てきやすい結論です。デプロイ手順を確認していなかったかどうかは程度問題であり担当者の主観によります。「しっかり」とか「確実に」とか、程度を示す言葉が書かれていれば要注意です。このような原因をおいてしまうと、「気をつける」みたいな主観ありあり、実効性のないアクションに結びつきがちです。

往々にしてポストモーテムを書くのはそのインシデントに詳しい人間が担当者になりやすく、インシデントとの距離が近ければ近いほど、主観をもって分析をしてしまいます。客観的な分析のための方法として、客観性を担保する方法として確実に有効なのは、第三者の利用です。例えば以下のようなものが考えられます。

  • インシデントとは直接関係のない人間が関係者にヒアリングして記述する
  • 主観的なワード（「しっかり」「確実に」など）を排除する

重要なのは、前者では「客観視できる人間の視点を入れる」、後者では「機械的に修正点を見つける」としているように、「インシデントを書く人間に客観性を求める」という精神論ではなく、分析自体も客観性のあるアプローチを取ることです。人間を変えるよりも環境を変えるほうがやりやすいということを前提とします。

単純か？

なるべく単純に、平易に、わかりやすく書くように努めるべきです。 先の例でいうと、以下のように複数の原因が複雑に記述されると、単純さを欠いています。

  • 原因1：デプロイ手順が複雑すぎた
  • 原因2：デプロイ手順を確認することの重要性が認識されていなかった
    • 新入社員研修のカリキュラムに含まれていなかった
    • 先輩社員によるデプロイ手順のレビューがなされていなかった
  • 原因3：スケジュールの都合上、余裕がなかった

複雑な原因が良くない理由として、3つ挙げて紹介します。

問題を正確に捉えきれていない

起きた事象が明確ならば、その原因も明確に存在するはずです。もちろん複数の要因が絡み合ってひとつのインシデントを形成する場合もありますが、ほとんどの場合は表面的な分析にとどまっており、深掘りが足りないケースが多そうです。起きた事象の記述自体が複雑ならば、まず事実確認まで立ち返ったほうがいいかもしれません。

アクションの実効性を落とす

複雑な原因から導き出されるアクションは、同様に煩雑になってしまいがちです。例えば上記例だと、原因が3つ挙げられているため、それぞれを解決するアクションを検討します。本来は「デプロイ手順を自動化する」というアクションが最も解決に近かったのに、「ドキュメントを整備する」「新人研修カリキュラムをみなおす」など、本質的でないアクションに陥り、運用コストや整備の工数が無駄に発生することになりかねません。

読みづらい

他のドキュメントと同じくポストモーテムもまた人間が読むことを想定した文書です。読みづらい文書を読みたい人間はいません。

原因をシンプルに落とし込むための手法としては、まずは愚直に「3行以内にまとめる」「1つだけにする」といった方法が考えられますが、実際に起きた問題が本当に複雑な原因を持っているケースも多々あり、本質的ではありません。

そこで掘り下げる方向での分析が必要ですが、手法は様々あります。有名どころでひとつ紹介しておくと、「なぜなぜ分析」があります。これは、トヨタ生産方式を構成する手段の一つです。方法はとてもシンプルで、「なぜ」を問い、それに答え、そうなった理由についてまた「なぜ」を問う、ということを繰り返していきます。

制御可能か？

コードやマネジメントのレベルでうまく制御できていれば解決していたのか、という視点です。 例えば前述のインシデント例で、制御不可能な原因は以下です。

  • 原因：ロードバランサが自動で切り離れなかった

振り返りの常ですが、結果論に陥りがちです。そうなっていれば起きなかったこと、を挙げること自体は間違いではないのですが、起こったあとだから言えることは当時知り得ないことなので、原因とは言えません。この例でいうと、自動化されていなかったことが原因として起きる問題というのは本来ありえないはずで、人の手で行ったことにより生じた不具合が原因としてあり、それに対するアクションとして「自動化」が挙がるのが正しい姿です。

制御可能性に関するもうひとつの大きな視点として、「人間はそのとき最善の判断をした」ことを前提とすることも重要です。SRE本にはそのように書いてあるのですが、「Google様は神エンジニア集団だからその前提でいけるけどウチは無理」と解釈しがちです。これは不遇な誤解だと思っていて、人間に原因を求めないというのは組織やサービス改善の重要な指針になりますし、そもそも人間は改善できないです。人間がミスったと思うなら、なぜその人間はミスったのか、深掘りすべきです。

まとめ

根本原因分析は、多くの場合に正解がなく、主観や複雑さとの闘いでもあり、非常に難しいです。

あらゆるロールの人間がインシデントに向き合い、その貴重な機会から学びや改善を得るために、根本原因分析をがんばっていくといいと思います。

偉そうに書きながら私もまったくできていません。しかし、思考の訓練をしながらそのスキルを上げていくことができると思っています。

他の組織での話もぜひ聞いてみたいので、ご興味のある方はコメント欄か@kabaomeまでご連絡ください。やっていきましょう。

参考

*1:https://landing.google.com/sre/books/

*2:法律上の定義はないため、参考文献より引用

扁桃切除手術の記録

生活

扁桃切除手術*1を受けました。
退院後、周囲の人がいろいろと聞いてくれたり、扁桃切除を検討しているので教えてほしい、と聞かれることが幾度かあったため、ここに記しておこうと思いました。

基礎知識

どういう手術なのかを簡単に紹介します。

扁桃とは

まず扁桃という器官は、喉にあるリンパ器官です。 リンパ器官というだけあって、鼻や口から入ってきた細菌やウイルスをとらえる免疫の役割を持っています。

免疫機能が未熟な子どもは、扁桃の機能に頼る割合が高く、ウイルスや細菌に感染しやすいのですが、成長するにつれて扁桃以外の免疫機能が発達してくるために、感染しにくくなってきます。それにつれて、扁桃自体も徐々に縮小します。 ただし、幼少期に扁桃炎を頻発するなどで、大人になっても比較的大きなサイズを保つ人もいます。

ちなみに「扁桃」というのはアーモンドの種子の別称です。 アーモンドの種子に形がにているという理由でこの名前がつけられたらしいです。 かつては「扁桃腺」と呼ばれていましたが、「腺」というのは身体の中で分泌活動を行う器官の名称であり、以後の研究によって腺の役割ではない説が有力となったため、現在では「扁桃」と呼ばれています。

扁桃には「咽頭扁桃（アデノイド）」「耳管扁桃」「口蓋扁桃」「舌扁桃」の4つがありますが、一般に扁桃と呼ぶ場合、口蓋扁桃を指します。

口蓋扁桃摘出術とは

口蓋扁桃を切除する手術です。 以下を基準として、手術適応か否かを判断されます。

  • 習慣性扁桃炎
    • 年に3,4回以上の頻度で急性扁桃炎になるひと
  • 扁桃周囲膿瘍
    • 急性扁桃炎になりすぎて炎症が周囲に波及し、膿瘍になったひと
  • 扁桃肥大
    • 睡眠時無呼吸症候群で扁桃が大きい*2ひと
  • 病巣扁桃
    • 扁桃が他の疾患*3の原因になっているひと

自分の場合は習慣性扁桃炎と診断されました。 扁桃肥大ぎみでもあったのですが、頻繁に喉を起点とした風邪をひくためです。明確な検査があるわけではなく基本的に自己申告です。

経緯と注意点

かかりつけ医の診察から退院までの経緯をメモります。

診断〜入院

入院に至るまでに複数のステップがあります。

  • かかりつけ医で診断＆紹介状取得
  • 大規模病院で診察＆手術の予約
  • 術前検査（手術1週間前）
  • 検査結果説明＆入院手続き

手術を受ける病院の選定

多くの場合、かかりつけ医からの紹介状をもって大規模病院で手術をうけることになります。 いきなり大規模病院*4に行くと、選定療養費として初診時5,000円がかかります。

どこの病院にするかはかかりつけ医と相談ですが、口蓋扁桃摘出術を都内で受けるなら、神尾記念病院、JR東京総合病院あたりが有名なようです。ただ、口蓋扁桃摘出術は耳鼻咽喉科の手術としては基礎中の基礎らしく、どこで受けても特にリスク等違いはありません。手術前後で数回の通院を考慮して、自宅から近い病院にするのをオススメします。

自分の場合も自宅から近い東邦大学医療センター大橋病院にお世話になりました。2018年6月に新病棟が設立されたばかりで、とても綺麗でした。10日間ほど寝食を過ごすため、自分にとっては綺麗な病院というのはとても重要な要素でした。

入院までの心構え

重要なのは、入院直前に風邪を引かないこと、虫歯にならないことです。 ここまでの検査や10日間のお休み調整がすべて無に帰します。 虫歯がダメなのは、手術のときに口の中にいろいろと突っ込むので、悪い歯があるとさらに悪くなったり欠けたりするから、と説明されました。

費用と高額療養費制度の活用

口蓋扁桃摘出術はどの病院でも10日前後の入院を要するため、高額療養費制度が使えます。 これは、医療費が一定額*5を超えた場合に、その額を上限としてオーバー分を国が負担してくれる制度です。ここで注意されたいのは、以下の点です。

医療機関や薬局の窓口で支払う医療費が１か月（歴月：１日から末日まで）で上限額を超えた場合、その超えた額を支給する

例えば、10月25日に入院して11月4日に退院した場合、「10月25日〜31日」と「11月1日〜4日」はそれぞれ独立した医療費とみなされ、高額療養費制度の上限はそれぞれに適用されます。したがって費用を最小に抑えるためには、月をまたがない入院期間を設定する必要があります。自分の場合は1日オーバーして、トータルで10万円強の負担となりました。

また、入院は病室によってグレードがあり、例えば個室を希望すると高くなります。差額ベッド代は高額療養費に含まれません。病院都合で差額のあるベッドになる場合もあるので、初期段階で合意しておいたほうがいいです。高額療養費制度や差額ベッド代など、費用面について、病院側は信じられないくらい無頓着で、数万円は誤差くらいの勢いでこられます。一般庶民の我々が積極的に情報を収集し、交渉していく必要があります。

入院〜手術

お昼ごろに入院し、その日は手続きや検査などを済ませるのみでした。 手術はオンコールといって、呼ばれたら手術室に行くというスタイルのため、ソワソワしながら待っていました。結局14時ごろに呼ばれ、看護師さんに案内されて歩いて手術室に行きました。道中の風景はまさにドラマや映画でみるやつで、楽しかったです。

手術自体は全身麻酔なので、気づいたら寝ていて起きたらすべてが終わって自分のベッド、というかんじです。 点滴をつけたまま、喉の痛み止めを飲んで就寝です。

術後〜退院

手術翌朝、起きたらベッドとパジャマが血で染まっていました。ありがとうございました。

喉が痛すぎかつ発熱もあり、世界を恨みました。看護師さんはクールです。

入院後半は出血もなく食事も平常にとれる状態になったため、退院を希望したのですが、「術後一週間時点に出血リスクがある」とのことで、入院を継続しました。このあたりはおそらく以下の論文が論拠になっていると思われます。統計的に有意なのかという疑問はありますが、専門外すぎてわかりません。

ヒマはヒマなのですが、喉の痛みと微熱はあり、活字をよむのはなかなかしんどかったので、主にマンガを読んだりラジオを聴いて寝落ちしたりしていました。キングダムとバクマンを全巻読みました。最高におもしろかったです。ファルファル。

退院日は片づけと手続きを済ませ、午前中には自宅に帰っていました。翌日からは喉をいたわりつつも普通に過ごしました。

その後

退院から一週間後に経過観察のための受診をし、特に問題ないとのことで、運動やお酒も解禁されました。 退院直後は喉の違和感が残っていましたが、退院から10日が経ち、もうほぼ通常どおりに生活しています。

まとめ

体調が改善したかはまだわかりません。がんばっていきたいです。 なお、最近は扁桃切除せずに凝固術や抗生剤で治療するのが主流らしいです。 それらを試して改善が見られなければ、切除を検討されるといいかもしれません。

参考

*1:正確には「口蓋扁桃摘出術」

*2:マッケンジーの分類によりⅡ°以上

*3:掌蹠膿疱症・IgA腎症・胸肋鎖骨過形成症

*4:大学病院などの「特定機能病院」と、病床数500以上の「地域医療支援病院」

*5:収入に応じて決まる

技術書典5にサークル参加した記録

技術

88年生まれ同い年の同僚たちと3人で、サークル名【88】として参加し、自分は『RDBMSのナカミ』という本を頒布しました。

BOOTHにも出品しています。

kabaome.booth.pm

pdfのみ122ページ、500円です。500円あれば100円均一の商品が5個買えると思いきや、消費税があるのでダメですね。話を戻します。ご興味ありましたらどうぞ。

参加の経緯

7月末頃、TwitterのTLで技術書典の存在を知りました。昼食を共にした同僚2名とその話になり、勢いで応募したら当選しました。技術書典どころかコミケなど同人イベントに一般参加すらしたことがなかったので、「"サークル"って何ぞ…？」くらいの状態でした。

各自思い思いのテーマで書き、当日までに3人とも仕上げて無事頒布することができました。よくがんばりました。我々。偉すぎ。

収支

目的は締切駆動学習ですが、せっかくの同人イベントなので、収支も簡単に紹介します。

当日76冊、その後BOOTHに出品し現時点で14冊をご購入いただいています。合計で90冊。よって売上は 500円×90=45,000円 です。一方、個人の費用は合計で約5,000円です。

  • 参加費(割り勘): 約2,300円
  • 見本誌製本、DLカード印刷: 約1,700円
  • ブース設営グッズ(割り勘): 約1,000円

以上より、40,000円程度の利益です。赤字にならなければ万々歳、くらいの気持ちだったので、まあ良かったです。

もちろん、これ以外に膨大な著者の時間と労力が投入されています。そういう意味では超絶赤字です。真紅です。利益を得る目的なら絶対にオススメしません。バイトとかしてください。

よかったこと

初のサークル初参加、諸々含めて、大成功だったと思っています。後世のためにやってよかったことを挙げてみます。

3人でやった

1人だったら確実にモチベーションが切れていました。RE:VIEWで書き、Bitbucketで管理して、Circle CIでEPUBをビルドして、Slackにポスト、としていたので、他者の進捗が通知されてきていいかんじに焦りを生成していました。

また、合同誌ではなくそれぞれ独立した本にしてよかったです。テーマが近しいならともかく、別々なら各自が責任をもつスタイルがよさそうです。お互いにレビューし合うこともでき、そのために前持った締切をお互いに設定しあえる環境もよかったです。最高の仲間。

割り切った

まず、応募直後の段階で紙をあきらめ電子版のみにしたのは完全に英断でした。締切が極度にタイトになり、生産コスト、在庫コストを抱えるのは、初参加かつお作法を知らない状態ではリスクが大きいです。当日の設営や撤収も瞬殺でした。「紙版があったら買ったのに」という損失は（0ではなかったですが）想定していたほどはなかったように感じます。

また、値段を500円均一にしたのもよかったです。オペレーションがシンプルでした。ちなみに他サークルをみるかぎり、500円はかなり安い部類です。原価がかからない電子版にしたからこその価格設定です。

毎日書いた

たとえ1行でも、帰宅が遅くとも、とにかくなにかを書いて進めました。自分は筆が遅い自覚があるし、未知のことを勉強しながら書いていたので、直前ブーストは確実に無理だとわかっていました。

また、これも自分の特性上、途中で途切れるとモチベーションもそれに応じて減衰するので、注意を維持する意味でもよかったです。

早めにした

紙を諦めたことで入稿の締切からは解放されましたが、諸々の納期を早めに設定し＆共有したことで、初参加にもかかわらず直前や当日のバタバタはほぼなかったです。天才すぎますね。

他の2名はわかりませんが、自分個人としては、最終週は何もやることがない状態でした。印刷物など外部発注系は真の詰みがありますし、早めであればあるほど安いです。精神的にも安泰です。

余裕すぎて、技術書典直前の土日は温泉旅行に行っていました。そしたら台風が直撃して、飛行機が飛ばないかもってなりました。危うく技術書典に参加できないところでした。

f:id:kyabatalian:20181009220258j:plain
客室からみた風景（自慢）

ノリで応募した

結局のところこれです。やってみようかな〜と思ったらとりあえず応募してみて、当選したらやれる範囲でがんばる。それだけ。

所感

執筆、サークル参加の両面で、とてもよい体験ができました。執筆面では、知らないことや、わかっているつもりがまったくわかっていないことの連続で、もはや勉強にしかならなかったです。サークル参加の面では、自分が書いたものを目の前でいろいろな人が読む様を、眺めているだけで楽しかったです。

自分のテーマは超絶シブく、50代の太った男性が主なターゲット層だと思っていたのですが、港区という名の異世界から迷い込んだのかな？と思わせるようなメイクバッチリの淑女や髪型ガッチガチの紳士が、弊見本誌を鋭い目で眺めている姿をみて、嬉しくも不思議な気持ちになりました。

反省としては、もっと会話をすればよかったなと思いました。後半はたまにこちらから聞いてみたりしていて、そのやりとりに価値を感じました。言い出しっぺとしてはサークルメイツにいい体験をしてもらいたいという意図もあったので、最初からグイグイ聞けばよかったです。

全体的に、美少女ラブみたいな空気感だったり、サークル通行証の説明文がなにかアニメ？のパロディっぽい文章だったりするのが、ちょっと自分にはきつかったです。同人文化において自分がマイノリティという自覚はあるので、やめてほしいとかは別に思いません。

運営はじめサークル参加の皆さまに対しては本当に心苦しくも、買いたいと思う本がなく、戦利品は0冊です。自分は技術！最先端！同人文化！サイコー！みたいなテンションではないですし、技術的な情報は基本的に公式ドキュメントや一般の商業誌で十分です。これは、自分の本のテーマ自体にも現れていますが、自分は最先端のイケてる技術を追いかけるよりも、積み上げられてきた理論を知り理解することのほうが楽しいと感じるためかもしれません。

今後

次回の技術書典にもサークル参加するかもしれません。そんな元気はないかもしれません。そのときもたぶんテンションで決めるんだと思います。そういうものですよね、人生って。

一方で、自分のエンジニアとしてのアウトプットは、ソフトウェアやサービスでありたいという思いも湧いてきました。本を書いて終わるのではなく、そこで得られた知識をものづくりに活かしていきたいです。明日からまたお仕事がんばろう。優等生のコメントっぽい。

さいごに

現地でブースに立ち寄り、またBOOTHから買っていただいたみなさま、本当にありがとうございました！！！！！！感想、コメントなどなど、ツイートやブログなどでお知らせいただけると、吐くほど喜びます。

サークルメイツの本もBOOTHで買えます。こちらも合わせてどうぞ。

tkrtkhsh.booth.pm hokkai7go.booth.pm

PowerShellでマルチスレッド処理(仮)

技術

夏が終わりそうで切ない。

切ないので、何の気の迷いか、PowerShellの激軽なメモを書いてみる。

やりたいこと

3秒待ってprocessの連番を出力するだけの処理。これを5回繰り返す際に、並列でやらせたい。

function Do-Process()
{
    param([int] $process_num)

    $tid = [threading.thread]::CurrentThread.ManagedThreadId
    Start-Sleep -Seconds 3
    Write-Host "theadId:$tid, process:$process_num"
}

まず、直列のほうを実行する。

function Test-Sync()
{
    foreach ($i in 1..5)
    {
        Do-Process ${i}
    }
}

$time = Measure-Command {
    Test-Sync
}

実行結果はいかのとおり。

PS C:\temp> .\parallel_test.ps1
theadId:14, process:1
theadId:14, process:2
theadId:14, process:3
theadId:14, process:4
theadId:14, process:5

1から5まで順番に、単一のスレッドで実行されている。これをマルチスレッド化したい。

Workflowを使ってやる

Workflowってなんぞ？って人は、Windows PowerShell ワークフローについてをどうぞ。

workflow Test-Parallel()
{
    foreach -parallel ($i in 1..5)
    {
        Do-Process ${i}
    }
}

$time = Measure-Command {
    Test-Parallel
}

実行結果は以下のとおり。

PS C:\temp> .\parallel_test.ps1
theadId:9, process:5
theadId:4, process:3
theadId:11, process:1
theadId:12, process:2
theadId:6, process:4

処理の順番はバラバラで、スレッドも異なっている。 マルチスレッドで処理されている。ようにみえる。

PowerShell 3.0の時点では、-parallel はシングルスレッドで処理されていたらしい。

blogahf.blogspot.com

MSのひとも以下のように言っている。

As an Activity author you can’t make any assumptions about what thread your activity will be invoked on or how that thread will relate to any other thread used by any other activity.
Windows Workflow Foundation (WF4) Activities and Threads – Ron Jacobs

謎。かしこい人、教えてください。

Background jobsでやる

PowerShell 2.0以降では、jobをbackgroundで起動できる。

docs.microsoft.com

Invoke-Asyncでやる

パフォーマンス的にはBackground jobsを使う方法に劣るが、スレッドの管理がラップされていてシンプルに書けるらしい。

gallery.technet.microsoft.com

補足

今回使ったWindows PowerShellは、長年Windowsにくっついていた歴史とぬくもりのあるPowerShellであり、.NET Frameworkでできている。WIndows PowerShellのWorkflowは.NET Framework 3.0で導入されたWindows Workflow Foundationという技術を基盤にしている。

一方で、.NET Coreを基盤としたPowerShell Coreもある。ただ、こちらにはWorkflowが移植されてない。

github.com

そのため、お手軽にはマルチスレッドの処理ができない。以下のようにがんばることになる。

winscript.jp

環境

Windows 10。

PS C:\temp> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.15063.1209
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.15063.1209
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

参考

お笑いライブのすゝめ

生活

お笑いライブはいい。

一般に、「お笑いが好き」という人はけっこう多い。テレビでは日夜バラエティ番組やネタ番組を始め、あらゆる場面でお笑い芸人をみる。また都内では、毎日どこかしらでお笑いライブが開催されている。こういった状況にも関わらず、お笑いライブに行ったことがある人は、少なくとも自分の観測範囲内にはほとんどいない。

ただでさえ人間との会話に難がある私が、唯一の趣味といってもいいお笑いの話を封じられると、何も喋れなくなって厳しい。

そこで本記事では、私がお笑いライブを推す理由と、都内近郊で気軽に行けるお笑いライブ、その中でも自分が行ったことがあるものを中心に、分類して紹介する。

すすめる理由

趣味は仕事と違い、他者に価値をもたらす義務がない。従って、その価値を他者に言語化して説明するのは野暮である。良いから良いということでしかないが、それを言っていても人々はお笑いライブに行かない。そこで、あえて書いてみる。

心身の健康にいい

自律神経系に良い影響があるとまことしやかに噂されている(要出典)。そもそも自律神経とはなにか。なにもわからない。エンドルフィンによる多幸感や、セロトニンによる抗うつ効果など、眉唾な研究結果()もある。

これらを置いておいても、嘲笑や愛想笑いなど特別な場合を除いて、一般に「笑う」ということ自体が良い行為であることは議論の余地がなさそうである。例外なくポジティブであり、笑うと楽しい。楽しいと笑う。哲学者ベルクソンは、著書『笑い』において、笑いの健康に対する作用として「緊張からの放心」と「考える疲労からの休息」を挙げている。体感的にもこれは妥当に思える。

笑い (岩波文庫 青 645-3)

笑い (岩波文庫 青 645-3)

テレビでいいと思うかもしれないが、劇場に赴き「みんなで笑う」という行為は、想像以上に気持ちのいいものである。

テレビより1億兆倍おもしろい

たまにお笑いライブを他者におすすめすると、「テレビでみれるからわざわざライブにいかなくても…」という意見を頂戴することがある。これに異を唱えたい。

演劇や音楽のライブと同じく、お笑いにおいても、その場が持つ空気感、一体感は独特なものがある。テレビでお笑い芸人をみて「なんでこんなにおもしろくない芸人が売れているんだろう…」と思うことは多々あると思うが、実際に生でみると、彼らがとんでもないレベルで仕事をしていること、そのすごさを体感できる。こればかりは本当に行ってみないとわからない。

趣味としてのコスパがいい

劇場に行くと、テレビに出ている芸人さんたちが、目の前でネタやトークをやっている。料金は無料のものから数千円のものまであるが、それでも演劇やミュージカルと比べて破格といえる。

また後述するが、これから人気が出ていくであろう若手芸人を発掘するのも楽しみの一つである。地下アイドルやインディーズバンドを応援するような感覚で楽しめる。 ネタが洗練されていく過程や賞レースでの躍進などを間近で楽しめる。

プロから笑いを買える

唐突だが、異性とのデートを企てている若者たちは、ぜひお笑いライブをその選択肢に加えてほしい。この時点で、本ブログを読んでいるような層は、「自分には一切関係がない話だ、読み飛ばそう」と思うかもしれない。そうに違いない。ただ、ちょっとまってほしい。我々のような層にこそ、お笑いライブを一手として持っておくべきなのである。

異性とのデートにおいて、「楽しませる」ということは非常に需要なKPIである。ここでの要点は、我々のような層は、会話によって人間を楽しませる能力が信じられないくらい低い、ということである。そのため、何を話したら良いかわからず、混乱し、錯乱し、支離滅裂な発言をし、やがてすべてを失う。終焉の訪れである。

そこで、お笑いライブに行くことを考える。そうすると、「楽しませる」という部分を、まるっどプロにお任せできるのである。だいたいのおいてデートなど、その中での細かい会話などは案外覚えていないものである。「楽しかったな」「めっちゃ笑ったな」という印象が残れば上出来であり、それは必ずしも自身で達成しなくてもよい。自分が楽しませなければというプレッシャーによる負のループから抜け出することができる。

また、若者の一般的なデートとして、映画鑑賞が挙げられる。映画館に行って2時間座って鑑賞し、終了後にカフェなどで感想を言い合う。ここで重要なのは、人間は他者からよく思われたいというバイアスがかかるということである。人間は汚い。面白くなかったとしても、口頭ではなんとでも言える。それに対し、お笑いは笑うか、笑わないかである。より根源的でシンプル。同時に、笑いのツボが一致しているかも確認することができる。

お笑いライブ

ここまでで読者はお笑いライブに行きたくてたまらなくなっているはずなので、いくつか紹介する。

冒頭で述べたとおり都内近郊では毎日どこかでお笑いライブが開催されているが、その趣は多様である。
今回はお笑いライブに行ったことがない人に向けて、その概要を紹介する。

事務所ライブ、独立系ライブ、単独系ライブ、賞レース予選ライブと、勝手に分類する。

事務所ライブ

お笑い芸人を要する各事務所が、定期的にライブを開催している。 吉本興業がスケール的にも別格なので、よしもととそれ以外で紹介する。

よしもと

泣く子も黙る国内最大手お笑い事務所。
都内にも、ルミネtheよしもと@新宿、ヨシモト∞ホール@渋谷をはじめとてて、複数の劇場をもつ。 テレビでも見たことあるメジャーどころの芸人さんのネタや、よしもと新喜劇を楽しみたい方はルミネ、若手芸人のライブを安価で楽しみたい方は∞ホールをおすすめする。

∞ホールでは、その中でも突発のものからレギュラーものまで、様々なライブがほぼ毎日行われている。他者事務所と比較して、養成所やノウハウがあり、若手芸人であっても安定感がある。有力若手芸人が勢揃いする『JET GIG』をおす。休日の午前中から夕方にかけての公演が多く、直前でも比較的席が空いているので、急な予定も合わせやすい。

注意点としては、良くも悪くも玉石混同、かつ2時間に渡ってネタが続くため、かなりの疲労感がある。このあたりは個人差もあるが、体力に自信のある方、メジャーどころだけでなく次世代の若手にいち早く目をつけたい方はぜひチェックされたい。

よしもと以外

表にする。順不同。

事務所 主な所属芸人 拠点 特徴 事務所ライブ関連のURL
ワタナベエンターテイメント ネプチューン・ブルゾンちえみwithB・厚切りジェイソン・平野ノラ・四千頭身 表参道 左記のとおり、近年大ヒット芸人を続々と排出している。 ライブ情報｜ワタナベエンターテインメント
人力舎 東京03・アンジャッシュ・ドランクドラゴン・アンタッチャブル・バカリズム・卯月 新宿 コント中心の芸人が多い。その影響で事務所ライブ「バカ爆走！」では、芸人登場時に拍手をしないことで有名。 EVENT イベント : JINRIKISHA OFFICIAL WEBSITE プロダクション人力舎オフィシャルウェブサイト
浅井企画 キャイ～ン・ANZEN漫才・流れ星・ドドん・ジャイアントジャイアン 新宿 萩本欽一氏、小堺一機氏、関根勤氏を排出し、「人間味あふれるお笑いのプロ集団」として知られる。 ライブ・イベント | 浅井企画｜タレント・芸人・文化人 芸能プロダクション
ホリプロコム バナナマン・スピードワゴン・磁石・きつね 新宿 芸能事務所ホリプロのお笑い部門。渡辺正行氏主催のお笑い団体「M2カンパニー」が前身。 ホリプロお笑いライブ | ホリプロコム オフィシャルウェブサイト | HORIPROCOM Official Site
ソニーミュージックアーティスツ バイきんぐ・アキラ100%・湘南デストラーデ 千川 厳密には事務所内の「SMA NEET Project」がお笑い部門に位置する。バイきんぐ小峠氏曰く、「あらゆるオーディションに落ちた芸人崩れが最後に行き着く事務所」らしい。 SMA お笑いライブ会場“びーちぶ”
マセキ芸能社 出川哲朗・狩野英孝・ニッチェ・三四郎・ジグザグジギー・さすらいラビー 新宿 エクストラシルバー、ライラックブルーなど、ランク別ライブのライブ名がダサい。 マセキ芸能社 MASEKI GEINOSHA Official Site
太田プロ アルコ＆ピース・アイデンティティ・新宿カウボーイ・ノブナガ ？ 老舗事務所。かつてはビートたけしや片岡鶴太郎が所属しており、テレビ一時代の長だった。 ライブ情報 | 太田プロダクション
タイタン 爆笑問題・日本エレキテル連合・ウエストランド・XXCLUB 阿佐ヶ谷 私の推し事務所。事務所ライブにいくと長井秀和氏によるテレビ完全アウトなネタがみれる。 ライブ | TITAN

その他、松竹芸能という超大手から、ビートたけし率いるオフィス北野、サンドウィッチマン率いるグレープカンパニーなどなど、大中小含めて様々な事務所がある。

独立系ライブ

事務所以外にも、ライブ主催団体がいくつかある。お笑い好きのおじさんが趣味でやっている謎ライブもあったりして、本当に当たり外れが激しい。

K-PRO

主に都内のお笑いライブを主催する団体。

お笑いライブ・イベント制作 Ｋ−ＰＲＯ

新宿、下北沢、中野などを会場に、ほぼ毎日お笑いライブを主催されている。 若手を中心に、事務所や芸歴問わず様々な芸人さんが出演する。たまにある大規模なライブでは、各事務所から豪華ゲストが出演するにもかかわらず比較的安価で、非常にコスパがいい。

様々なランクのレベルがあるが、初見だとわかりにくい。はじめていくなら、バティオスネタ祭り、V-1ネタ祭り、超ボルケーノ寄席、スペシャルブルームあたりが間違いない。次世代の若手をみたいなら、ブレナイなどもいいかもしれない。

U&Cエンタープライズ

同じく都内のお笑いライブ主催団体。

uandcenterprise.jp

K-PROほどではないが、こちらもかなりの頻度でお笑いライブを主催されている。エントリー制のライブから上位ライブまである。比較的、女性の芸人さんの出演が多い気がする。

下北GRIP

毎週金土日に開催される無料ライブ。

shimokita-grip.com

ライブ前の時間になると、下北沢駅、ピーコックの前で芸人さんたちが呼び込みをしている。会場はすごく怪しい場所にあって入りづらさ満点だが、けっこう満席だったりする。メイプル超合金やゆにばーすなど、ちょっと前までここで呼び込みしていた芸人さんがスター街道をのし上がっていくのをみるのが楽しい。

無料とはいえ、ライブ運営のために最後に芸人さんたちが出口で募金を募っているので、このブログを見て行かれる方は、ぜひ心ばかりの援助をされたい。

ラスタ原宿

ワンコイン500円で昼夜公演のあるお笑いライブ。

lastaharajuku.wixsite.com

休日になると原宿竹下通りで芸人さんたちが呼び込みをしている。場所柄客層は極めて若く、従ってコアなお笑いというよりはアイドル的な芸人だったり、軽めのネタがウケる。端的にいうとチャラい。かのブルゾンちえみ氏もラスタ原宿出演から人気が出た。

ちなみにラスタ原宿という名前は、劇場オープン時に出資してくれた小島よしお氏をリスペクトしてつけられた。現役の芸人である、ザ・ビリーバーズの延籐氏が代表を務める。

単独系ライブ

事務所ライブと異なり、特定の芸人さんが主体となるライブもある。

単独ライブ

特定の芸人さんが好きになったり、応援したいという感情が芽生え始めたら、単独ライブをおすすめする。
会場費などある程度の集客力を前提とするため、本当の駆け出しの芸人さんはあまりない。ある程度のファンがいて、賞レースで勝負をかけたい層が主になる。
会場を埋めることに苦労する芸人さんもいれば、チケット即完や、全国ツアーをやる超人気芸人もいる。気になる芸人さんがいたら、まず直近の単独ライブの情報を調べてみるといいかもしれない。

芸人主催ライブ

単独ライブと似ているが、こちらは芸人さんが自身だけでなく他の芸人さんを呼んだり、合同で主催するライブもある。

例を挙げると、バラエティ番組で活躍する若手芸人が賞レースに勝ちたい場合、単独ライブを主催してネタを試したくても、観にくる客さんは熱烈なファンが大半になってしまったりする。そこで、客観的視点でネタを試すために、複数の芸人で合同のライブを実施し、相互のファンの目を入れる、などがある。

また、相方をシャッフルしたり、ネタのテーマを縛ったり、個性的かつ挑戦的なものも多い。普通のネタライブ以外が観たくなった場合や、好きな芸人さんの新たな一面をみたい場合におすすめである。

賞レース予選ライブ

M-1をはじめとする賞レースの予選リーグは、通常のお笑いライブと同じく観覧することができる。芸人さんが本気ネタでしのぎを削るため、ライブとしての品質も極上である。決勝はテレビ番組のため、ショーと割り切って観るのがよく、むしろ予選リーグこそ若手芸人の本気が観られる。

賞レースは無数にあるが、今回はテレビ放映もせれてもっとも知名度の高いと思われる、M-1、キングオブコント、R-1を挙げる。

M-1グランプリ

日本一の漫才師を決める大会。 予選が8月から始まっており、年末にかけて2回戦、3回戦、準々決勝、準決勝と選抜されていく。決勝は年末のテレビ放映される。

プロだけでなくだれでも参加できるため、1回戦は真の玉石混同で、プロの芸人はもちろんだが、ノリで出場した大学生や、果ては夏休みの絵日記のネタにと参加した親子コンビなどもいる。 2回戦、3回戦と進むに従って選抜されていき、3回戦ごろにはほぼアマチュアは淘汰されている。

人気芸人の本気ネタが安価で鑑賞できるライブでもあるため、チケットが非常にとりづらい。準決勝などはチケット転売サイトで高値が取引されていた。発売と同時に即購入ください。

キングオブコント

日本一のコント師を決める大会。 M-1よりやや早く、7月から予選が始まって、決勝は秋頃にテレビ放映される。準決勝は9月だが、現時点で前売りチケットはすべて完売している。観覧希望の方は来年にご期待ください。

R-1ぐらんぷり

日本一のピン芸人を決める大会。 年末に予選が始まり、3月初旬の決勝にかけて選考が進んでいく。決勝はテレビ放映される。 昨年は盲目の漫談家である濱田裕太郎氏が優勝して話題となった。

M-1やキングオブコントに比べるとまだチケットが取りやすいはずなので、ご興味ある方は春頃にそのつもりで。

お笑いライブにいくデメリット

ない。

さいごに

テレビでみて気になっている若手芸人がいれば、まずその名前でググればTwitterアカウントや事務所のライブ情報が出てくるので、行ってみるとよい。気になる芸人さんがいない場合は、まずはヨシモト∞ホール、もしくはK-PROのスケジュールを確認されたい。最初なら以下の条件を満たすライブをおすすめする。

  • なるべく多くの芸人が出演する
  • 料金が1500円〜2000円程度

今後数ヶ月は、M-1とキングオブコントに向けた対策ライブが頻繁に行われる、いわばオンシーズンといっていい。ぜひ見に行って、各自の推しをみつけてもらいたいし、その話題をもって私の話し相手になってほしい。

本当は私の推しの芸人さんについて述べたいが、この余白はそれを書くには狭すぎる。

『SRE サイトリライアビリティエンジニアリング』を読んだ

本 技術

いや、夏やん。ってなってる。この勢いで気温が上がるのだけはマジ無理。マジ溶ける。

どんな本か

www.oreilly.co.jp

著者はGoogle社のSREチームの主要メンバー。

サイトリライアビリティエンジニアリング（SRE）とは、Googleで培われたシステム管理とサービス運用の方法論です。

従来のシス管やDevOpsといった概念とは異なる新たな方法論について、Googleの実サービスの例を挙げながら紹介されている。

日本語訳の本書が発売されたタイミングで話題になったが、SRE自体はかなり前から一般用語化しており、先進的なｳｪｯﾌﾞの会社では早々に取り入れ、SREという職種で採用募集されていたりする。以下をさらっとみて、もっと知りたいと思ったら本書に手を出せば良さそう。

原文は全文がWebで公開されている。英語できるマンはこれ読んでください。解散。

なぜ読んだか

10余年にも渡って取り組んできたSREという体制について、天下のGoogle様が出し惜しみなく赤裸々に語った本ということで、ミーハーだから買った。あわよくばお仕事に活かせることがあればいいなあというかんじ。

インターネッツで英語版を読んでも良かったが、ただでさえ分量が多く英語力が皆無なので、金の力で翻訳版を得た。会社の金で。

全体の感想

情報量がすごい。ページ数もさることながら、濃い。濃密。実質3万ページくらいあるのでゎ。

全34章と細分化されつつも、各章は独立して体系的にまとまっている。ので、章のタイトルを見て、気になるところを拾い読みするのがいいかもしれない。自分もハードウェア構成とかあまり関係なさそうなところは読み飛ばしたりした。

周囲の評判どおり学びが多く、例によって消化しきれていない。ただ読んだだけでは意味がないと思いつつも、単なる技術本とは違い個人が明日すぐに使える知識というわけではない。自分が携わるサービスに対してなにかできないか、SRE的な視点をもって現状を見てみるところからはじめていきたい。

「第9章 単純さ」が好き。なぜなら、シンプルさが好きだから。複雑なのが苦手だから。本章自体シンプルでポエミーで抽象的だが、SREの本質を的確に表現していると思う。重要なのは、本質以外は切り捨てる勇気。

「第12章 効果的なトラブルシューティング」もオススメ。トラブルシューティングは偶発的に起こる作業であるために、属人的、職人的になりがちで、その手順は明文化されていない事が多い。そんな中で、トラブルシューティングの一般的なフローを明記し、汎用的な思考パターンを提示されていて、いろんな場面で判断の材料になりそう。

「第15章 ポストモーテム文化：失敗からの学び」は某社社員にオススメ。捉え方の問題でもあるし、まだまだいくらでも改善の余地があるとポジティブに捉えられた。伸びしろですね。

「第23章 クリティカルな状態の管理：信頼性のための分散合意」は、主に分散合意アルゴリズムPaxosとその亜種について解説されている。自社のサービスで分散合意を直接意識することはないが、個人的に合意アルゴリズムには興味がある。おそらく、日本語でここまでまとまったPaxosの解説はない気がするが、理解できておらず、歯がゆい。自戒を込めてここに記録し、何らかの手段を持って理解し、本書を再読したい。

「第27章 大規模なプロダクトのローンチにおける信頼性」も某社社員にオススメ。というかたまたまいま自分の中でホットトピックだった。仕組みと構造化。やっていき。

「第33章 他の業界からの教訓」はおもしろいアプローチ。過去に他業界*1で働いていた現Google社員にインタビューし、SREの文化とプラクティスがどう適用されるのか、あるいはさらに学べないかを考察している。あらゆる業界において障害対策は本質的な課題であり、ディザスタテストやポストモーテムの文化、自動化、構造化といった考え方は、Google社あるいはITサービスに限定せず、あらゆる業界で有益そう。

各章の最後に「Google SREが推奨する参考文献」が紹介されている。ほぼすべてめっちゃ面白そうだったが、きりがないので涙をのんで追うのを諦めた。実践してみようと思う章があれば、そこの参考文献は目を通すと良いかも。

著者のひとりであるBen TreynorのインタビューがWebで公開されている。本書をひととおり読んだあと、あるいは読む前にさらっとみて意識を高めるといいかもしれない。

細かい感想

気になったところを引用しつつ、感想を書いておく。いま時点での自分が感じたことをオープンな場で記録しておくことに一定の価値がある気がする。知らんけど。

第Ⅰ部 イントロダクション

従来の開発プロセスが抱える問題と、それに対する仕組み、それらを包括するSREという概念について紹介されている。後半はGoogleのプロダクション環境について紹介されているが、いろいろ次元が違って参考になりそうもないのでいったんみなかったことにする。

「好きなものを好きなときに邪魔なしにローンチしたいんだ」対「いったん動いたシステムは一切変更したくないね」(p.4)

この本、というかSREという概念が解決したい課題を端的に示している。従来の組織では、開発チームと運用チームが分断されていて、前者は早くリリースすること、後者はシステムを安定稼働させることをミッションとしており、本質的に目的が対立関係にある。

SREとは、ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるものです。(p.5)

よくわからない。俺達は雰囲気でSREをやっている。

ソフトウェアエンジニアがソフトウェアを設計する際に一般に意識する拡張性·信頼性·耐障害性などを、運用チームという組織の設計にも適用した場合、ということなのかもしれない。例として、『スケーラビリティ』という概念を運用チームに適用する。サービスの成長やユーザの拡大に伴って、運用メンバー（リソース）が線形に増えていく組織は、スケーラビリティが低いといえる。サービスが成長しても最小限のリソースで運用できる仕組みを構築することが、SRE的なチームの『設計』なのかもしれない。知らんけど。

GoogleではすべてのSREに対して、チケット、オンコール、手作業といった「運用」業務の合計を50%以下にするよう、上限を設けました。(p.6)

SREが従来の運用チームと異なるのは、主業務があくまでもエンジニアリングであること。運用な前述のとおりリソースを追加することによってある意味では達成可能。それに対してSREは、運用業務を最適化するようなエンジニアリングを行う。放っておくとリソース投下に走る力学が働くので、ルールとして明文化しているのだと思う。

ここで問題になるのは、その50%をどうやって計測するのか、ということ。SREに限らず、一般にエンジニアの業務の計測は、コストと精度、その必要性のバランスの中で難しい課題で、実際にうまくいっている例をみたことがない。最も原始的には各自が、自分が何にどれだけ時間をつかったかを記録しておくことだが、個人の裁量に委ねられているが故に、精度もまちまちになってしまう。スクラムやカンバンといった開発プロセスのフレームワークはひとつの解決法になるのかもしれないが、ことSREに関しては、新規機能開発と違ってスコープの不明確性やイテレーションで単純に切れないプロジェクトが大半なため、性質上、そのようなフレームワークとは特に相性が悪いと思える。うまいことやってる方いれば教えてください。

100%を信頼性の目標とすることは、基本的にいかなる場合にも間違っている(p.8)

Google様がおっしゃっておられあそばされますのでそのとおりです。99.999%を100%にするのは労力にわりに対価が乏しいから、他のことやれよ、ってことよ。では信頼性の目標をどう決めるのかというと、それはもうプロダクトごとに特性をみて定義していきましょう、でしかない。どれくらいであればユーザは満足するか。本書においてわりと重要なキーワードである『エラーバジェット』というものがあるが、これは次部ででてくる。

第Ⅱ部 原則

SREとして仕事を進める上で、原則となる考え方や指針を示している。

私たちはリクエスト成功率という観点から可用性を定義しています。(p.29)

可用性=成功したリクエスト数/総リクエスト数 、らしい。ドシンプルすぎて感動した。サービスの可用性は、ユーザ及びサービス運営側にどれだけの不利益を与えたかで定義されるが、計画外の停止時間やシステムの稼働時間など、パラメータが多すぎて難しい。それにしてもすごい。リクエストってそれぞれ価値はことなるはずで、例えば「サービスにログインできない」と「OGP画像が表示されない」を同一のリクエストとして扱っていいのか、など。それをあえてどシンプルに振り切っている。本当にやりたいことに対して最短·最適な効果が出るように設計されている。

エラーバジェットが提供するのは、1つの四半期内でサービスの信頼性がどの程度損なわれても許容できるかを示す、明確で客観的なメトリクスです。(p.37)

第Ⅰ部にも書いてあったとおり、従来の開発／運用チームの課題は、それぞれの目標が対立していることにあった。その間を取り持つ仕組みとして、『エラーバジェット』が提案されている。その名のとおり、四半期内で『損失可能な信頼性』という『予算』を設定する。開発チームは、四半期のエラーをその予算内に収めるようにリリースを行う。これによって、開発とSREとで共通の指標を持つことができる。

これも前述と同じで、指標の単純化にかなり振り切った仕組みになっている。私が関わっている某サービスではNewRelicを使っているが、その中でApdexという指標がある。エラーバジェットとは異なるが、主にパフォーマンスという観点でサービスの可用性を担保するシンプルな指標となっている。基本的には「Apdexがある数値(デフォルトで0.95)を割らないように維持する」だが、とはいえ…みたいなケース（画面）もある。そういった例外的な場合にどう対処するのか、具体例をもっと知りたいと思った。ので、教えてください。

自分たちが計測できることではなく、ユーザが気にすることは何かを考え（あるいは知り）ましょう。(p.46)

サービスの振る舞いに関する目標を設定するとき、ついつい計測可能なものをベースに考えてしまいがち。計測が困難だったり、近似が必要だったりすることも多いが、意味のない指標を追い求めるよりははるかに有益。集計が必要なできるだけシンプルにする。設定した目標を定期的に見直し、修正を加えていく。また、過剰達成を避ける（インセンティブを与えない）。

トイルとは、プロダクションサービスを動作させることに関係する作業で、手作業で繰り返し行われ、自動化することが可能であり、戦術的で長期的な価値を持たず、作業量がサービスの成長に比例すると行った傾向を持つものです。(p.51)

toilは、直訳すると「労苦」。本書におけるtoilとは上記の定義。単に「めんどくさい作業」ではなく、自動化できるのにできてない、長期的に価値がない作業のこと。自動化できないということはすなわち『人間がやるべき仕事』ということであり、排除すべき作業とはいえない。GoogleのSREにとって、各エンジニアの作業時間にしめるトイルの割合を50%以下に抑える、という目標があるらしい。逆の見方をすると、Google様クラスのエンジニアでも、放っておけばトイルが50%を超えるということであり、こわい*2。具体的には、割り込み対応、緊急対応、リリース対応の順に多いらしく、これは普段のお仕事の体感とも合致する。自分はわりかしトイルは少ないほうだと思うが、メンバーの中には

トイルの悪い点について、「キャリアの停滞」「モラルの低下」が挙げられていて、意外な角度だと思った。「つまらない仕事からキャリアを生み出すことはできません」エモい。日々の運用作業でついつい仕事をしている気になってしまうが、思考停止にも陥りがち。人間は易きに流れる。運用という性質上、他の業務より優先度が低く設定されて長期的にみると莫大なコストになってしまう。SREという組織がそれを明に目標として持つことで、改善していこうという話。

しっかりと考慮すべきなのは、すべてのページを独立したイベントと捉えるのではなく、ページの全体的なレベルが健全で持続可能なチームと長期的な展望をもたらし、ひいては健全で適切な可用性を持つシステムへとつながることになっているかということです。(p.69)

ページというのはユーザに対する通知＝アラートと読みかえてよさそう。ある特定の機能の問題発生時にアラートメールを開発者に飛ばす場合、そのメール単体ではなく、他のアラートメールや機能に対する優先順位などの位置づけを踏まえ、サービス全体として適切なアラートを設計する必要がある。また、長期的に見ればそのアラートメールの根本原因をつぶすことが最適な場合もある。重要なのは、アラートも機能の一部としてきちんと『設計』する、という考え方。

私たちが面倒を見ているプロダクトやサービスは地球全体に及ぶ規模を持っており、他の組織では一般的なやり方でマシンやサービスの面倒を見るような時間が私たちにはないのです。(p.74)

Google様～～～～～～～！！！です。というのは置いておいて、自動化の話。Google規模になると、運営するサービスにおいて自動化による一貫性、素早さ、信頼性のメリットは非常に大きく、もはや自動化 or 手運用の議論が不要なほど。一方で、我々のような一般人の運営するサービスはそのレベルにはなく、自動化のコストを踏まえて本当に適切化を判断する必要がある。重要なのは、サービスも日々成長していく中で、ある時点で自動化が不要となっても、数日後には自動化したほうがいいという判断にもなりうるということ。都度適切かつ客観的な判断をいれること、その計画をたてておくべき。

Googleにおいて、リリースエンジニアリングは明確に一つの職能と位置づけられています。(p.91)

自分や自分の職場にはあまりない観点だと思った。リリース作業はある程度は自動化されているものの、手作業の部分は残っているし、ヒューマンエラーやいわゆるトイルも潜んでいる。ちょうどひとつ前に書いたとおり、最近のリリース頻度をみるに、がんばって自動化するに足る箇所なのかも、と思った。

私がこれまで行ったコーディングで最も満足感を抱いたのは、その時点でもう意味がなくなっていた数千行のコードを削除した時です。(p.103)

わかりすぎる。わかりすぎて泣く。稼働するサービスに追加されるコードは、その一行一行が潜在的に負債といってもいい。何かの機能を実現するためのコードは小規模かつ単純であればあるほど価値がある。拡張性や耐障害性とのトレードオフともなりうるため、どちらかに傾倒しすぎないように、設計時には単純さの観点もようよう含めるべき。

APIが小さくて単純であるということは、問題が十分に理解されているということの証明である。(p.103)

完全にわかりみ。
外部に向けたWeb APIに限定したものではもちろんなく、クラス設計におけるインターフェイスでも同様。インターフェイスに対してプログラミングをする、というオブジェクト指向の設計原則でもいえることだが、インターフェイスをみて何ができるか、どの場面で使うかがイメージできれば、プログラミングの12割は終わったようなものである。頭ではわかっていても、実際やってみるとなかなかうまくいかない。がんばりたい。

第Ⅲ部 実践

だいぶ具体的になってきたものの、実サービス・組織に直接適用できそうな考え方が詰まっている。

サービスの健全性は、Abraham Maslowが人間の欲求を分類した方法と同様に、システムがサービスとして一通り機能するための最も基本的な必要条件から、自己実現を可能とし、問題に樹頭的に対応するのではなく、サービスの方向性を能動的にコントロールするような、より高いレベルの機能に至るまでの段階に分類できます。(p.107)

かの有名なマズローの欲求段階説と同様に、サービスの健全性も段階的に高次になっていく、というおもしろい発想。一番下の層が『モニタリング』になっているのが響いた。まずはサービスの状態、現状を把握してはじめて、どうしたいかを考え始めることができる。また、最上位は『プロダクト』となっている。信頼性を満足なレベルまで高めて初めて、プロダクトは完成する。耳が痛い。

Googleはまた、DiRT（Disaster Recovery Training）と呼ばれる全社規模のディザスタリカバリのトレーニングを年に一度行っています。(p.138)

緊急対応が少ないシステムはいいことだが、運用不可が低すぎると、いざ問題が発生したときに対応できない。エンジニアは厨二病発症者が大半なので、シャカイに対して斜に構えがちで、避難訓練とかをないがしろにするイメージがある*3。そういうのはやめたほうがいい。人もサービスも死んだら取り返しがつかない。避難訓練と同じで、いかに対象者に価値を感じてもらう避難訓練を設計するかはかなり難しい課題だと思う。ここも各社の事例をもうちょっと知りたいところ。

緊急対応の体制についても、みんなどうしてるんだろう。少なくとも本書では、開発チームとSREチームが独立しており、SREチーム内で緊急対応の当番制になっているように読める。別のやり方として、緊急対応を開発チームで受け持つという形もありうる。問題が発生したときに、その機能に詳しい人が担当したほうが、解決までの速度は速いはず。もちろんコストや体制との兼ね合いでもあるので、その組織にとってベストな設計にすべきではある。

否定的な結果が出た実験は決定的なものです。そういった実験は、プロダクションや設計の領域、あるいは既存のシステムのパフォーマンスの限界について、何らかの確実なことを示します。(p.150)

少なくとも、実験したことは、本番でも同条件下で確実に起きうる。否定的な結果を出し尽くすことは、サービスの信頼性を高めるためにとても有益。また、その結果を公開することで、周囲に価値をもたらす。人間はついつい見えを張って、失敗を見せたくなかったり、よく見せようとしてしまう。本当にチームのことを考えるなら公開するべき。

新たなタイプの障害が発生するたびに、対応者たちはその障害の様子を書き記しました。(p.165)

それなりの規模でサービスを運用している組織なら、障害対応ののちに、次に同様の障害が起きないようにどうするべきか、起きたときにどうするべきかを振り返るはず。重要なのは、振り返りをして満足するのではなく、その実効性を担保すること。ヒューマンエラーなどの場合には「気をつける」などのパッション的な結論に陥りがちだが、そこで深掘りし仕組みに落とし込むこと、それを組織に周知·徹底することまでやりきらなければ意味がない。「その対応を書き記す」というのは、何が起きたかをメンバー間で合意し、対応に応らなかったメンバーにも同レベルの理解を確認できるという意味で、その第一歩といえる。記録を取るというのはどうしても優先度が下がりがちだが、大切にしていきたい。

Googleのインシデント管理のシステムは、明快でスケーラブルであることで知られるIncident Command Systemに基づいています。(p.169)

ICSは、災害や事件の現場における標準化されたマネジメントシステムらしい。知らなかった。読んでみたい。しんどい。

うまく設計されたインシデント管理のプロセスは、「責任の再帰的な分離」「明確な司令所」「ライブインシデント状況ドキュメント」「はっきりとした引き継ぎ」という特徴を持つとのこと。まとめると、「人の判断や責任において、あいまいな境界を作らない」ことに尽きる。だれがいつなにをするべきかを明確に規定し、それを共有できていること、お互いに信頼することが必要。システム設計と同じく組織の設計においても、高凝集、疎結合を意識すべき。

レスポンスに対応している間の自分の感情の状態に注意を払いましょう。(p.173)

インシデント対応の大前提として、冷静·客観的に対応を進めることが必須。感情的な判断は被害を拡大させる。インシデント対応に限らず、自分は自身の感情を把握·制御することが苦手なように感じている。感情を把握·制御するのもスキルのひとつだと思うので、別途トレーニングしていきたい。

ポストモーテム文化を育むための継続的な投資によって、Googleのサービス障害は減り、ユーザ体験を改善できています。(p.181)

ポストモーテムとは、インシデント発生時に、そのインパクトと対応、原因、再発防止策を記録するもの。障害報告書とは異なり、社内のエンジニア間で、同様のインシデントを発生させないための学びを得ることを目的としている。以下3点が重要だと感じた。

  • 非難しない: 人間を変えることはできないが、仕組みを変えることはできる
  • レビューする: 下書きを広く公開し、客観的情報の記述や対応内容をレビューし、積極的に共有する（参照できるようにしておく）
  • 称賛する: ポストモーテムを残すことはトイルではなく組織改善に有益なことなので、適切な報酬を得るべき

この点は某社でも大いに改善の余地がありそう。ちなみにGoogleでは大量に蓄積されてきたポストモーテムを機械学習に食わせて弱点の予測などを行っているらしい。さすが。

テスト対象のコンポーネントには、障害が起こるまで負荷をかけましょう。(p.294)

自分はカスケード障害に備えた視点でのテストがあまりできていないと感じた。

カスケード障害((ポジティブフィードバックの結果として、時間と共に拡大していく障害(p.273)))においては、通常の過負荷による障害と異なり、フィードバックという複雑系の中で、(対象のコンポーネントに限らず)システム全体として何が起こるか予測困難である、という前提に立ったテストが必要となる。

そのため、単に想定される負荷をかけて耐えられることを確認するだけでは不十分。障害が起こるまで負荷をかけることにより、実際に何が起こるのかや、その状態を避けるために割くべきリソースとのトレードオフが議論できる。さらに困難なのは、本番環境になるべく近い環境でテストする必要がある。場合によってはプロダクションテストも検討すべき。

データの完全性を考えるにあたって重要なのはクラウド上のサービスがユーザーから利用可能であり続けることなのです。(p.357)

例えデータは無事でも、ユーザからアクセス不可能な状態が長時間続けば、それはデータがなくなったのと同じ。つまるところ、データの完全性は手段であり、目標とするべきはデータの完全性である、ってはなし。

データの損失は、アプリケーションのバグやヒューマンエラー、ハードウェア障害など、様々な原因がある。あらゆるケースを想定して、なるべく早くリカバリ可能なように様々な手をつくしておく。「多層防御」って言葉かっこいい。そのためには、サービスに求められる安定性の要件（SLO）を定義し、それが満たすことを検証する、という過程が必要。明確かつ合理的な目標値がないと、見えない基準に向かってあれこれ手を出し、不安で夜も眠れなくなってしまう。とにかくテスト。

どんなものもいつかはおかしくなるということを認識できれば、それはあらゆる本物の緊急事態に対して備えるための大きな一歩になります。(p.388)

まさか自分が、まさかうちのサービスに限って、と楽観的になりがちであり、障害の予防は優先度が下がりがち。バックアップとか、だれにも感謝されない。障害が起きたときの甚大な被害は、経験していないとなかなか想像しづらいのが現実かもしれない。システムの安定性要件（SLO）が定義されており、そのテストを含めて担当者を適切を評価すべきだし、経験豊富(なはず)の偉い人がそこを整備し、説いていくしかない。セキュリティとかも同じ。

ローンチが失敗するさまざまな形を予測し、ローンチに関わるさまざまなエンジニアリンググループ間の調整を行った結果、SRE内には特別なチームができあがりました。それがローンチ調整エンジニア（Launch Coorination Engineers = LCE）です。(p.390)

サービスのローンチが頻繁であればあるほど、そのプロセス設計には価値がある。LCEはローンチのプロセスの整備や教育をし、実際のリリース時には旗振り役になり、経験と客観的視点を持ってローンチ作業とその後のサービス信頼性を担保する。

Googleは2004年にLCEを設立している。最先端すぎ。そこから10数年の経験がLCEに蓄積されており、そこから見出した、良いローンチプロセスの特徴が興味深い。「軽量」「頑健」「綿密」「スケーラブル」「適応的」。これらを満たすために、Googleでは、「基本を抑えたローンチプロセスを設計しておき、個別の事情に適宜カスタマイズする」という方策をとっている。がっちがちのルールを設計して運用に乗らなければ意味がないが、クリティカルな障害だけは防ぎたい、という本質的な課題に取り組むことになる。おもしろそう。

本章後半では、LCEが解決しなかった問題も紹介しており、興味深い。基本的に変化に対して弱いっぽい。

第Ⅳ部 管理

初期の学習経験：混沌ではなく構造を提供する(p.414)

これですね。SREに限らず。崖から突き落として這い上がらせるシステムは、教育ではなく選別。対象者はその意義を理解できないまま盲目的に作業するだけになり、何も得られない。特にSREの障害対応は、本番を通じて学習する、という機会がなかなかなく、また実際に起きたときは教育している場合ではなかったりするので、単なるエンジニアよりもさらに教育が難しい。

新人をオンコール担当に導くまでの教育プラクティスが紹介されているが、中でも「ポストモーテムの読み込みと共有」は有益だと思った。障害はなかなか一般論では説明できず個別のサービスに条件が絞られる。そこで蓄積されてきた障害とその対応がまとまっている文書は、唯一の教科書となりうる。そのためにも、そのためにもポストモーテムの整備は価値がある。

また、「ディザスタロールプレイング」というミーティングが紹介されていて興味深かった。過去に起きた障害のシナリオをなぞって、どういう行動をするか、そこからどういう情報を得たかなどを会話で進めていく。Googleでは伝統的にこの演習をやっており、「不運の輪」（Wheel of Misfotune）と呼ばれているらしい。いちいちかっこいい。

生産性が継続的に失われるのを避けるには、作業のスタイルの間で時間を二極化しましょう。(p.434)

主にSREが割り込み作業にどう対処すべきかについても言及されている。二極化するというのは、自分のプロジェクト「だけ」をする時間なのか、わりこみ作業「だけ」をやるのかを自分でわかっているようにせよ、ということ。割り込みをシャットアウトし、集中的に取り組む時間も設ける。メリハリきっちりしましょうってはなし。まあこのへんは本質的かつ永遠の課題。それぞれの環境で試行錯誤しましょう。

第Ⅴ章 まとめ

私がGoogleに加わった時点では数百人だったエンジニアの集団だったSREは、今では1,000人を超えて10箇所以上のサイトに広がり、(p.493)

え、でか。もとからでかいんかい。思ってたよりめっちゃでかい。ここまで読んでて想像していたよりでかい。とはいえ、SREの目的のひとつは信頼性観点でのスケーリングであり、規模にかかわらずあらゆるサービスに必要な考え方ではある。信頼性に価値がある文化を根付かせる存在。

GoogleのインフラストラクチャやSREチームが経験してきた変化や成長にもかかわらず、その発想の誕生から10年が経過してもSREという職務は柔軟で古びることがなく、その目標も当初のままです。(p.494)

裏を返すと、Google様ともあろう存在が10年かけても解決しない課題ともいえる。ソフトウェアに限らず、サービスを提供する上で、信頼性のエンジニアリングは本質的な課題ってこと。たぶん。なので、がんばっていきましょう。

*1:航空機やライフセーバー、海軍など

*2:本書記載の時点では33%とのこと

*3:個人の主観です

GW京都旅行の記録

京都 生活

GWの後半(5/3-6)を利用して京都に行った。 良かった。

本ブログは技術ブログであると同時に京都良さみ啓蒙ブログでもある。そのため、今回京都滞在時に行ったところを紹介する責務がある。

清水寺とか金閣・銀閣とか辻利とか、そういうベタなやつは当然ない。ネイティブ京都人なので、精神がねじ曲がっており、そういったベタな観光スポットを冷ややかな目線でみている。実際には人混みが嫌いすぎるだけ。

続きを読む