だいくしー(@daiksy)のはてなブログ

daiksyの徒然的なもの 以前のブログはこっち -> http://daiksy.blogspot.jp/

2020年のふりかえり

今年でいよいよ後厄が終わります。コロナなどでたいへんな一年でしたが、公私ともに充実した良い一年でもありました。

去年はこんな感じでした。

daiksy.hatenablog.jp

買ってよかったもの

例年はあまり「買ってよかったもの」と言われてもピンとこない生活を送っていますが、今年は就業環境をリモートに本格的にシフトさせ、そのために身の回りを整えました。

その1. 昇降デスク

緊急事態宣言以降ずっとリビングで仕事をしていたのですが、メンタル的にも限界を感じたので意を決して買いました。

気分によって、スタンディング、バランスボール、椅子など仕事のスタイルを切り替えられます。

個人的にはふりかえりなどのファシリテーションをするときは、立ってやるとなんとなく気合が入ってやりやすいです。

その2. セイルチェア

昇降デスク購入後、一月くらい立って仕事をしていたのですが、やはり疲れるので椅子を買いました。なにげに今年最も高額な買い物かもしれません。

家にオフィスチェアを置くと、なんとなく見た目のバランスが悪い気がしていて躊躇していたのですが、知人のデザイナーさんが家に置いても違和感がない、とツイートされているのを見て買いました。

次の写真が在宅ワーク環境完成形です。

f:id:daiksy:20201229124838j:plain
こういう環境で仕事してます

その3. PS5

すべての抽選に外れまくって当分入手は無理かと諦めていたのですが、縁があって正規価格で入手できました。 開封した瞬間、目の前にある製品の実在が信じられないやら嬉しいやらで膝がガクガク震える、というこれまでの人生になかった反応を身体がしめし、不思議な感じでした。宝くじに高額当選した人とかもこういう気持ちになるのかもしれません。

月別のふりかえり

さて、月別の活動のふりかえりです。

1月

コロナ禍以前の生活がどうだったか、もうあまり思い出せませんね...。ほとんど記憶がありません。カレンダーを見ても別に特別なことはしていなさそうでした。

2月

デブサミに登壇しました。もともと公募セッションに申し込んだのですが、セッション内容が先方のもともとのタイムテーブルの構想とマッチしたということで、招待講演枠に移動するという特殊な感じでした。

今年はこれをきっかけにさまざまな執筆やオンラインイベントのお誘いがありました。特に今年は、その後の執筆活動によって、自粛生活の中でも一つやりがいのある仕事が得られてメンタル的にもずいぶん助けられることになります。この機会がなければ今年1年の生活はずいぶん違ったものになっていたかと思うと、少しぞっとします。

event.shoeisha.jp

speakerdeck.com

このデブサミが今年自分が参加したリアルに人が集まる形式の最後の登壇になりました。

この数日後、PIXIV TECH FES. に招待いただいていたので参加してきました。

conference.pixiv.co.jp

デブサミ -> PIXIV TECH FES 参加ため、土日を挟んで数日間東京に滞在していました。ちょうどコロナウィルスの市中感染が広まりはじめたころで、せっかく土日を東京で過ごしていたのに、なにやらおそろしくて1日中ホテルに篭もっていました。

PIXIV TECH FES. も懇親会が中止になり、その翌週からは他のイベントも次々と中止。今思えばギリギリのタイミングでした。

3月

デブサミの講演をご覧になった技術評論社の方からコンタクトがあり、編集者さんと一緒に目次を作り始めました。最初はデブサミの講演内容をそのまま記事化する予定でしたが、何度か編集会議でフィードバックをもらい、最終的に「障害対応演習」に絞った記事になっていきます。

このあたりの時期から会社にはほとんど行かずに、それ以降ずっと在宅勤務が続いています。

4月

オンライン飲み会をやりはじめたり、それに高速に飽きている様子がカレンダーから伺えました。

5月

EM.FMに出演しました。Podcastの出演はなにげにはじめてかもしれない?? 激変する周辺環境をどうマネージメントするか、みたいな話をしていました。

anchor.fm

こちらもデブサミの記事がきっかけで、ProductZineというCodeZine内に新設されたメディアの記事を書かせてもらいました。 編集者さんとのMTGの末、会社として連載枠をいただき社内でのキュレーション活動などもやっていました。

codezine.jp

Findyのメディアにお声がけいただき、自分のキャリアについての記事を書かせていただきました。

engineer-lab.findy-code.io

ちなみに、これまで原稿料をいただいて書いたWeb記事で、100ブックマークを下回ったことはまだないのが密かな自慢です。

6月

認定スクラムプロダクトオーナーを取得しました。

f:id:daiksy:20201228111327p:plain

スクラムフェス大阪で登壇しました。 オンライン登壇なので少し変わったことがしたいと思い、チャットに寄せられる質問やリアクションにリアルタイムに反応しながら講演する、というのをやってみました。まぁまぁうまくいった手応えがありました。

www.scrumosaka.org

speakerdeck.com

7月

冬に続いて、夏のデブサミにもお声がけいただきました。前述のProductZineのつながりで、3人のリレーセッションでした。

event.shoeisha.jp

speakerdeck.com

8月

デブサミ関西にもお声がけいただき、1年で3回デブサミに登壇するという光栄な経験をさせてもらいました。 一般参加者として講演を仰ぎ見ていたあの頃の自分にこれを教えたら、たぶん信じてもらえないでしょう。

関西在住のエンジニアのキャリアについてのパネルディスカッションでした。 コロナによって奇しくもリモートワークが浸透し、それによって地方からでもさまざまなキャリアのチャンスに巡り会えるのではないかと期待しています。 自分自身、関西にこだわって暮らしているのですが、もしあのときに東京に行っていたら、今よりも高い年収になっていたのかもなー、などと妄想することは今でもあります。

将来、人々がまた自由に行き来できるようになったとしても、地方に住みながらにして良いキャリアが選び取れるような世の中は進んでほしいです。

event.shoeisha.jp

9月

夏のデブサミのセッションが好評で、それの再演ウェビナーがありました。

codezine.jp

去年に引き続き、文科省のenPiTという事業のお手伝いをしました。

aibic.enpit.jp

10月

3月から準備していた特集記事がついにお目見えしました。 おかげさまでたいへん好評のようで嬉しいです。

WEB+DB PRESS Vol.119

WEB+DB PRESS Vol.119

  • 発売日: 2020/10/24
  • メディア: Kindle

daiksy.hatenablog.jp

11月

あまり記憶がない...。

12月

去年からお手伝いしていた仕事がようやくお目見えしました。

daiksy.hatenablog.jp

来年のこと

1月発売の某雑誌にむけて実は記事を書いており、先日入校されました。また、春頃に発売される予定のとある書籍のお手伝いもしています。 このように今年はコロナの影響もあって例年より登壇やイベント参加は少なかったのですが、執筆関連の仕事が多くて家で自粛生活を続けつつもおかげで充実して過ごせていました。

これらの仕事が無かったら、たぶんめちゃくちゃ気が滅入っていたと思うと自分はとても幸運だったなと思います。

これらは2月のデブサミの講演がひとつのきっかけだったり、2019年からの仕込みだったりします。それらの仕込みはすべて使い切ってしまったので、来年は特に大きな予定もなくすこし不安な気持ちを抱えているのも事実です。

そのようなこともあり、自分のキャリアを落ち着いて見つめつつ、また大きめのチャレンジなどしていけたらなと思っています。

『わかばちゃんと学ぶサーバ監視』監修の裏話

12/22(火)に発売の書籍、『わかばちゃんと学ぶサーバー監視』と、それに先駆けて本の前半部分を技術書典で頒布した『マンガでわかるサーバー監視入門』を監修させていただきました。

わかばちゃんと学ぶ サーバー監視

わかばちゃんと学ぶ サーバー監視

  • 作者:湊川あい
  • 発売日: 2020/12/22
  • メディア: 単行本(ソフトカバー)

ここでは本の宣伝をかねて、監修って何をやったの? みたいな裏話を書こうと思います。

きっかけは?

ぼくは普段Mackerelというサーバー監視SaaSの開発チームのディレクターをしています。あるとき、著者の湊川さんと出版社の編集者さんから監修のご相談をいただき、お引き受けすることになりました。扱っているプロダクトの性質上、半分仕事みたいなものなのですが、仕事自体は個人でお請けした仕事という形です。

湊川さんからいただいたお話は、当初からMackerelを中心に据えてサーバー監視を説明する本にしたい、ということでした。しかしながら、これはMackerelの宣伝本ではなく、あくまでもサーバー監視についてわかりやすく説明する本にしたいという意向をお持ちで、その点についてはぼくも大いに共感しました。なので、Mackerelを取り上げている本をMackerelのディレクターが監修するという難しい立場ではあるものの、できる限り他のツールの紹介なども含めたフラットな視点になるように心がけました。

監修ってなにをするの?

基本的に構成や執筆は著者の湊川さんが進められていました。ぼくは湊川さんが作られた構成や原稿を確認し、誤りや気になる部分があれば指摘をしたり、湊川さんから質問が寄せられた場合はそれについて調査したり回答をする、という感じでした。

実はほんのちょっとだけですが、原稿の執筆もやらせてもらっています。特にどこがぼくの担当かは明記していないので、探してみて、ここかな、という箇所が見つかったらこっそり教えて下さい。あってるかどうかお答えしますw

あと、マンガの中に一瞬だけ登場したりもします。

f:id:daiksy:20201221175719p:plain

執筆前の事前の打ち合わせで湊川さんにお話したエピソードをマンガにしてもらいました。そういう意味では広義の意味では漫画原作者と名乗ってもいいかもしれません(名乗りません)。

難しかったポイント

今回、監修という立場で本の制作に携わるのははじめてのことだったのですが、やってみるとけっこう難しかったです。

単に内容のファクトチェックだけであるなら、そんなに悩むことはないのですが、ファクト的には正しいが、自分だったらこうは書かないな、という箇所を指摘するべきかどうかで悩むことが多かったです。

とくにこの本はマンガがベースになっていることもあって、湊川さんの解釈や表現をできる限り尊重したいというのを常に考えていました。湊川さんから見れば自分は専門家であるので、自分が指摘してしまった箇所について、著者さんの立場としてはそこは修正しようという向きに強くベクトルが働くだろうと考えました。なので、あまり細かく指摘しすぎてしまうとせっかく著者さんが自ら勉強されて得られた解釈を損ないかねません。ですので、ファクト的に正しい場合はあまり細かいことは指摘せずに、なるべく著者さんが書かれたテイストを守ることを優先しました。マンガはそのほうが絶対に楽しいものになると思ったからです。

ただ、マンガである前に技術書でもありますので、この件を言い訳にするつもりはもちろんなく、監修した自分にも当然責任はあると思っていますので、厳しいご意見などあればぼくの方に伝えていただけたらと思います。

とはいえ、技術書典で公開いただいた前半部分はたいへん評判がよく、そのテイストは後半部分にも続いていますので、最近のサービス監視について概観を得られる充分な読み応えのある内容になっているという自負はあります。

間違いなく読んで楽しい本になっていますので、ぜひお手にとっていただけたらと思います!

わかばちゃんと学ぶ サーバー監視

わかばちゃんと学ぶ サーバー監視

  • 作者:湊川あい
  • 発売日: 2020/12/22
  • メディア: 単行本(ソフトカバー)

エンジニアメンター1on1のやりかた

社内勉強会で発表した内容を外向けに編集して書きます。

ぼくが勤める会社では、エンジニアメンターという制度があります。

developer.hatenastaff.com

エンジニアメンターは定期的に1on1を開催するのですが、1on1は突き詰めて考えていくととても難しいものです。それこそちゃんとやろうと思うと、コーチングの専門的なスキルが必要だったりするわけですが、エンジニアメンターが全員プロ並みのコーチングスキルを保有する必要があるかというと、そんなことは無いと思っています (マネージャーなどの管理職であればそれなりにちゃんと勉強しておいてほしいですが)。

そこで、社内勉強会でエンジニアメンター向けに、このくらいのポイントを抑えておけばいいですよ、というのを伝えました。

ポイントは2つだけ

エンジニアメンター制度における1on1は、コーチングなどの専門的なスキルを学んで取り組まなければならないようなものとは異なると考えています。ですので、あまり難しいことを考えても意味はありません。誰もが気軽に開催して、時々でいいので「やってよかったね」と思えるくらいで充分です。

抑えておくべき点は以下の2点です。

  • 1on1の目的など考えない
  • 決められた頻度で必ず開催する

それぞれ理由を説明します。

1on1の目的など考えない

1on1のそもそもの目的は、チームでの仕事や、日々のふりかえりなどでは拾いづらい個人にフォーカスがあたった問題を拾い上げることだと思います。では、ここでいう「問題」とはなにか。それはそれぞれの状況や人によって異なるので定義できるものではありません。

「なにか問題を拾い上げないと」という目的意識を持って1on1を開催するのも悪くはないですが、ではその問題がなにも見つからなければ1on1の意味はないということになってしまうのでしょうか。問題が何もなければ、今は平和でよかったね、で終われば良いはずですから、そういう意味でも1on1を開催する目的、などというものは深く考えずに気軽な気持ちで開催したほうがよっぽど有意義だと思います。

なので、ここではあえて「目的など考えない」としておきましょう。

決められた頻度で必ず開催する

定期開催こそが1on1の最大の意味

こちらが1on1にあたってはとても重要です。1on1をやると、隔週や毎月、といった頻度で相手を数十分程度拘束することになります。ただでさえ日常の業務で忙しいのに、相手の時間を奪ってしまって良いのだろうか、と悩んでしまう人も多いです。そうすると人によっては、毎回特に問題点などないから、わざわざ開催しなくてもよかろう、今月はスキップしようか、などとやってしまいがちです。

1on1において最も大事なのは、「何もしなくても自動的に定期的に場が発生する」ということです。仮になにか悩み事をかかえていたとして、その悩みは誰になら相談できるのかを考え、その人に声をかけて時間を作ってもらって相談する、という一連の動きはなかなか骨が折れるものです。ですが、そういった労力をかけずに自動的に会話の機会が発生すれば、ちょっと話してみようか、という気持ちになることもあります。

人間はさまざまな「相談先」を持ちます。上司や同僚、友人、家族などです。抱えている悩みに応じて相談先は変わるので、複数の窓口に気軽にアクセスできる環境がとても大切です。1on1は、その相談先の窓口が常に空いていて、放っておいても自動的にその機会が訪れる、という状態そのものに最大の意味があります。

単純接触効果

もうひとつ、定期開催には重要な意味があります。

単純接触効果という言葉があります。ザイアンスの単純接触効果とか、熟知性の原則、となどで検索すると専門的な情報にアクセスできます。 これは、人間は接触する機会の多いものに対して親近性を高める、という社会心理学の分野で研究されているものです。

同じ"3時間"という時間でも、年に1回3時間会うのと、35日連続で5分ずつ会うのでは後者のほうが親しみが湧きます。

1on1は悩み事を相談する場であると書きましたが、あまりお互いのことを良く知らない同僚に深い相談ができるだろうか、という懸念はこれによって払拭されます。

仮に隔週で15分ずつ1on1を開催すると、1年でおよそ25回程度の頻度で接触機会があります。仕事上の問題を相談するという程度の、エンジニアメンター1on1の場では充分すぎる回数です。

人見知りの人など、1on1に抵抗がある人も少なくないと思いますが、最初の3, 4回我慢すれば単純接触効果によって特に気にならなくなりますから、こういう意味でも定期的に「必ず」開催することに意味があります。

監視の最初の一歩目とそこからの育て方

はやいものでもう12月。今年もアドベントカレンダーがはじまりました。

本エントリは、Mackerelアドベントカレンダー2020の初日です。

監視は難しい

Mackerelがローンチしてから6年が経ちました。この6年間、ぼくもほぼMackerelに関わる仕事をし続けています。6年前と比べて、多少はソフトウェア開発・運用の現場でも、監視の民主化みたいなものが浸透してきたかな、というのは感じつつあります。devopsというワードがバズワードではなく、エンジニア文化をあらわす一般的な用語として認知されつつあるのもそのあらわれでしょうか。

Mackerelを導入すれば、簡単に監視をはじめられますよ、と我々はお客さんに対して説明するわけですが、そうはいってもやはりまだまだ難しいところもあると思います。6年前に当時アプリケーションエンジニアとして正式ローンチ2ヶ月後にチームにジョインした当初のぼくなども、監視についてはほとんど何もわかっていませんでした。

今だとよい手引があります。

『入門監視』などはモニタリングについてひととおり学べるたいへんよい書籍です。

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

  • 作者:Mike Julian
  • 発売日: 2019/01/17
  • メディア: 単行本(ソフトカバー)

宣伝のようになって恐縮ですが、今回監修という立場で制作に関わらせていただいた、『わかばちゃんと学ぶサーバー監視』も、著者の湊川さんが苦心されて、マンガでたいへんわかりやすく最近の監視界隈をひととおり概観できる書籍になっています。

わかばちゃんと学ぶ サーバー監視

わかばちゃんと学ぶ サーバー監視

  • 作者:湊川あい
  • 発売日: 2020/12/22
  • メディア: 単行本(ソフトカバー)

監視すべき項目は環境によって違うから難しい

Mackerelの仕事をしていて、よく聞かれるのは、結局なにを監視したらいいのですか? CPU使用率の監視閾値は何パーセントにすると良いのですか? というようなものです。

「この項目に対して閾値をこれこれで監視すればよいですよ!」とズバッと一撃で回答できるとよいのですが、残念ながらそうはいかないところに難しさがあります。というのも、やはり実際に運用されているアプリケーションや環境によって、監視すべき項目というのは異なるからです。

たとえば、CPU使用率を監視して負荷を検知したい、と考えたとしましょう。たくさんCPUを使っている状態は負荷が高いから、80%くらいに閾値を設定すればよいのかしら、と考えたくなりますが、それがそうでもないのです。

オートスケール環境で、アプリケーションを並列に複数のサーバーで動かしている場合、インフラコストの効率化の観点でいえばCPUはなるべく使い切っているほうが効率がよい、となります。10台のサーバーで、それぞれのCPU使用率が60%なのだとすれば、まだそれぞれ40%の余力があることになりますから、台数を減らしてそれぞれCPU使用率90%くらいまで使い切ったほうがコスト面での効率がよい、と考えることができます。負荷が高まればサーバー台数を増やせばよいわけですから。

この場合、負荷はCPU使用率よりもloadavgであるとか、ネットワークトラフィックであるとか、他のメトリックを監視するほうが適切であるともいえるでしょうか。

一方で、簡単にスケーリングしづらいデータベースサーバーなどは、充分に余力をもたせて20%程度の使用率をキープしたい、ということもありえるでしょう。

このように、一口にCPU使用率、という監視項目をみても、アプリケーションの構成や考え方によって、検知したい閾値は大きく異なってくるのです。

悩んだら「ユーザーに近い場所」を監視する

さて、難しいとばかり言っていても先に進みませんから、まずはわかりやすく簡単にはじめられるところから監視を考えていきましょう。

そもそもわたしたちはなぜ監視をしたいのでしょうか?

サービスがダウンしていることに気づかず、復旧が出遅れてしまったり、ユーザーに迷惑をかけてしまうことがないようにしたい、というのがそもそも監視をしたい動機でしょう。

であれば、まずはユーザーがサービスを使えているかどうか、というのをはじめに監視するのがよいということになります。

MackerelにはURL外形監視という機能があります。

mackerel.io

これは、実際に稼働しているWebサイトに対してリクエストを行い、そのレスポンスを監視する機能です。

正常に動いていれば、サイトは200のステータスコードを返しているわけですから、そうでないステータスコードを受け取ったときにMackerelはアラートを発生させます。

まずはこれだけやっておけば、サイトがダウンしているのに数時間気づかなかった、というようなことは避けられます。ダウンしてまもなくMackerelからアラートを受け取ることができるからです。

この監視さえ一つ入れておけば、サイトのダウンには気付けるようになります。しかし、できることならダウンする前に、その予兆を察知したいですよね。なので少しずつ監視を育てていきましょう。

URL外形監視には、レスポンスを受け取るまでの時間に対して閾値を設定できます。サイトの応答が遅くなる、というのは何かが発生している予兆です。本来すぐに返事がくるはずのページが、たとえばデータベースの負荷がかかっているなどの理由で重くなっている状態です。

レスポンスタイムを監視すれば、サイトが完全にダウンしてしまうよりも少し前に気づくことができるかもしれません。

少しずつ監視を育てていこう

ステータスコードとレスポンスタイムを監視すれば、障害が発生した瞬間を捉えることができます。厳密に言えば多少の誤差はあるでしょうが、少なくともこのあたりの時刻で不調が起き始めたのだな、ということがわかります。

次に、それを手がかりに他のメトリックを眺めてみましょう。たとえば、レスポンスタイムのアラートが発生した時刻付近で、サーバーの他のメトリックに変調はなかったかどうか。アプリケーションサーバーのメトリックはいつもと変わりないのに、データベースサーバーのloadavgが大きく増えている、といったことがわかれば、原因はデータベースに近いところにあると判断することができます。では、次はもう少しはやく不調に気付けるように、データベースサーバーのloadavgを監視しましょう。継続的にメトリックをとっていれば、普段の正常な数値はわかるはずですから、そこから少し高い数字を閾値に設定します。

このように少しづつ監視を「育てていく」ことで、自分たちのアプリケーション特性に応じた監視項目が整ってくるのです。

ここで大事なのは、情報は普段から継続的にとっておく、ということです。

ある日の朝、体重計に乗ったところ80kgという値でした。この値だけみても良し悪しはなにもわかりません。身長とあわせて判断すればひょっとしたらもう少し何かがわかるかもしれません。ぼくにとって80kgという値は、いますぐ痩せなければならないたいへんな数値ですが、体を鍛えているがっしりした体格の人にしてみれば正常値かもしれません。今日のこの瞬間80kgだった、という数字にはなんの意味もないのです。継続的に計測していて、2ヶ月前は70kgだったのに今は80kgだ、というような継続的な情報の蓄積に基づいて判断してはじめて、数値には意味が生じるのです。

ですので、メトリックはなるべく多く、継続的に取得しておくのが良いでしょう。

メンテナンスしやすいサービスを選ぶ

監視項目は、普段の運用業務での傾向を眺めながら、継続的にデータをとり、チューニングしていくべきものです。

ですので、アプリケーションエンジニアやSREが、気軽に設定を試行錯誤できるようなサービスを選ぶべきです。必ずしもMackerelを使うべき、とは言いませんが、思い立ったらすぐに設定を変えることができるくらい身近に監視サービスがあるのが望ましい気がしますね。

それでは明日からのアドベントカレンダーも、よろしくお願いします。

ついに覚悟を決めて在宅ワーク環境を整備しはじめた

今年の3月から自宅で仕事をしているのだけど、緊急避難的な措置だと思っていたので特に環境を整えたりはせず、リビングで膝の上にMacbookを置いて仕事する生活を半年ほど続けてきた。

そうこうしていると勤め先から今後2年間のワークスタイルの方針が提示された。

pr.hatenastaff.com

仮にワクチンが発明されて新型コロナウィルスを気にしなくて良い世界になったとしても、今の在宅勤務とのハイブリッドな状態は長く続きそうな気配もあるし、意を決して自宅の環境をもう少し整えることにした。

去年の7月に引っ越して以来、ほとんど物置のように扱っていた部屋があるので、そこを仕事部屋にする。

まずは昇降デスクを買った。健康を意識し、スタンディングで仕事をしたいと思ったからだ。

1日中立って仕事をし続けるのも疲れるな、と思ったので、数年前にオフィスでつかっていたバランスボールを持って帰ってきたが、それはそれとしてちゃんとした椅子も欲しくなる(まだ買ってないけど)。

f:id:daiksy:20201111121244j:plain

不思議なもので、机に向かっているだけで仕事への集中度合いが全然違う気がする。

リビングと違って今の部屋にはスピーカーが無いので、Home Pod miniも買った。届くのが楽しみである。

www.apple.com

WDP誌で『インフラ障害対応演習』という特集記事を書きました - 内容と裏話 -

10月24日発売のWEB+DB PRESS vol.119 にて『インフラ障害対応演習』という特集記事を執筆しました。 ボリュームは25ページです。

経緯

今年の2月に、Developers Summit 2020というイベントで、下記のような講演をしました。

speakerdeck.com

これをご覧になった技術評論社の編集の方から、本講演を記事化しませんか、というお声がかかりました。

その後、記事化にあたってどういう構成が良いかを編集者さんと議論を重ね、最終的に講演のトピックの1つであった「障害対応演習」を深く掘り下げて記事化することとなりました。

記事の内容

記事冒頭の一部を引用します。

本特集では、障害対応を上手にこなすための方法の一つとして、障害対応を安全な環境で練習する「障害対応演習」を紹介します。 第 1 章では、障害対応の性質や課題と、それを解決するためになぜ障害対応演習が重要なのかを解説します。第 2 章では、筆者が業務で運用に携わって いる Mackerel という SaaS(Software as a Service)プロダクトにおいて、実際に行った障害対応演習の詳細を事例として紹介します。第 3 章では、昨今の社会情勢に伴ってニーズが高まっているフルリモートワー クの環境について、障害対応の観点から留意すべき事柄を説明します。最後に第 4 章で、障害対応演習で確認すべき大事なポイントや、演習を通して何を学ぶべきかを解説します。

このような内容になります。 かつての「動いているシステムは触るな」といわれた時代から、現代ではシステムが常に更新されつづける時代へと変化しました。そしてそれに伴ってSREという考え方が登場。これらの流れを簡単に解説しながら、障害対応演習の概要と、なぜそれが重要なのかを第1章で説明します。

読みどころは第2章です。Mackerelで去年実施した大規模な障害対応演習の実例を、当時の計画書や実施記録、担当エンジニアへのヒアリングなどからかなり赤裸々に書きました。

第3章では、昨今重要性が高まっている「フルリモートワークでの障害対応」について解説しました。第4章では、演習を通して、障害対応全体に適用できるような学習ポイントを紹介しています。

その他裏話

3月ごろから、編集者さんと企画を整理しはじめました。最初はデブサミの講演内容をそのまま記事化する形で考えていたのですが、技術評論社さんでの企画会議のフィードバックを得て構成を練り直し、7月くらいまでは編集者さんと一緒に目次をつくっていました。

7月, 8月の土日をすべて執筆にあてる、という形で執筆をしました。最初は30ページ弱ものボリュームをこのテーマで書ききれるか不安でしたが、事前にかなり詳細に目次を作っていたため、いざ執筆がはじまるとさほど迷わずに既定のページ数を埋めることができました。

企画段階もそうですが、全般的に編集者さんがとても的確にガイドをしてくれて、「著者と編集者が二人三脚で本を作るというのはこういうことか」というのを強く実感する日々でした。これまでも共著などで本の執筆に携わることはありましたが、編集者さんと直接やりとりする立場での執筆は今回はじめて(従来はメイン著者がいて、サブ的に執筆に関わっていたので)で、とても楽しかったです。

また機会があれば、なにか書きたいなと思います。

自分でも満足のいく良い記事が書けたと思うので、ぜひお手にとって読んでみてください。