@hihihiroroのLog

ダラダラと。本ブログは、個人の意見であり、所属会社とは関係がありません。

「システム障害対応の教科書」を読んだ

え?まだ読んでないの*1と言われたこともあり、ごめんなさい読んでませんと思いながら読んでみた。

読み始めていきなり分かるなと思う文章に出会った。

システム障害対応は未知かつ非計画的であるため、教育が難しい領域です。そして、多くの先輩たちがぶっつけ本番の障害対応の中で成長してきたのも事実です。それゆえに、教育が不可能と認識されていることも多いのです。
出典 : システム障害対応の教科書 | 木村 誠明 |本 | 通販 | Amazon p.13

自分も障害対応を行っているときにシステムのことを理解することが多かった経験がある。なぜかと考えてみると、障害を早急に倒すために詳しい先達が投入され対応している姿をみるので口伝や先達しか知らないことを学ぶ経験をすることが多い、必要なことだけ集中して話がされているので情報がよくまとまっているってことによるのかなと思う。

障害が起こった際のことは考えたくないので障害時を考えて準備しておく、練習をしておくということが少ないのかなと思った。ここ数年だとカオスエンジニアリングなどが話題になったこともあり障害が起きることは当たり前だと認識されているのではないかと思う。最近では障害を短い時間で終わらせるために対応方法を考えておく、練習を行うようにする事ができるといった考えをする人が大半な気がしている*2

本書は、属人化する、その時にしか思い出さないような暗黙知になってしまっている障害対応のノウハウが体系的に書かれた一冊になっている。
目次は以下

第1章 システム障害対応を学ぶ意義
第2章 システム障害の定義
第3章 システム障害対応の登場人物と役割
第4章 各プロセスの基本動作〜発生から終息まで
第5章 障害対応に必要なドキュメント
第6章 システム障害対応力を高めるツールと環境
第7章 組織の障害対応レベル向上と体制づくり
第8章 システム障害対応力の改善と教育 Appendix 難易度の高いシステム障害ケース

自分が障害対応時に行っていることは書かれていることとズレが少なかったので間違ったことをしていたわけではないのだろうと自信が少しだけ持てた。
特に以下のことを気にしながら僕は障害対応をしている。

  • 不明なことは不明と言って早めに広報
  • 復旧と言える状態の合意
  • 事実と仮設を混同せず作業をする
  • 振り返りを行う

特に振り返りは必要だろうなと思っておりポストモーテムを記載をするようにしている。
主に記載しているのは以下。

  1. 概要
  2. 障害原因
  3. 行った暫定対応
  4. 行うべき恒久対応
  5. 障害対応時系列記載
  6. 作業中に起こしてしまったまたは気がついてしまったヒヤリハット
  7. 広報した宛先、内容

1〜4 はトラブル自体、対応した内容について記載しているので当たり前だと思う。
5 の時系列に書かれている対応は後で読み返してみると対応方針や調査手段などを学ぶのにとても役立つ。他にも、復旧までにかかった時間がわかるので次回起きたときにユーザが影響受けるのがどれくらいか、復旧するために時間がかかってしまっているのがどこかを調べることができる。時間がかかっている箇所の手順を見直したり、ツールを開発することで障害復旧までの時間が短縮できる部分を見つけることができるので良いなと思っている。
またヒヤリハットでは作業ミスしそうになったこと、今回の障害とは直接影響ないが同じような障害がいつか起きそうなことが分かったなど次の障害の兆しを見つけるヒントになることが多いと思うのでオススメ。
これ以外にも必要なものなどあったら追加していきたいなと思っているので、みんなどうしているのか話し合ってみたりしたい。

まとめ

  • 効率的に障害対応について学べるなと思った
  • 今の自分たちが行っている障害対応について考え直してみようかなと思った
  • 公開されている障害情報や報告書を読んでみようと思った

*1:ここまでの言い方ではなかった

*2:障害が起きることを推奨しているわけではない。障害は起きないに越したことはない

202106 振り返り

太ったのではと恐れていたがついに確信を持つようになってしまった。
今月は健康診断もあるので辛い現実を突きつけられてしまうのだと思っているが真摯に受け止めなくては。

本を読むのは飽きてきたので小説とか漫画くらいしか読まなくなってきてしまった。
それとは別にカフェに行ってかき氷食べながらいろいろとおしゃべりしたりして楽しんでいる。

そろそろちゃんと勉強し直さないとなと思い始めているので、積読消化をまた再開しよう。
と、板チョコアイス食べながら反省している。もぐもぐ。

べんきょうかい

流し見ばっかりになってしまっている。
Scrum Fest Osaka はビデオ公開されているので毎日2つくらいを毎日見ている。
椎葉さんに後日社内の人に再公演をしてもらって話を聞くことができて面白かった。細かく気になったところ聞けるのでタメになったし涙が止まらなかった。

昔はアイス食べながらすぐにしゃべることができてた環境はありがたかったんだなーと思った。

ほん

小説をだいぶ読んだ。特に三体を読み終えたのは満足感がある。
漫画は順調に読みすすめることができているのは良かったなー。
積読消化よりもどこかで紹介されていた、見かけたなどで気になった本を買って読んでいた。

えいが

どれも面白かったな。コロナ禍だから混んでない時間などを頑張って選んで見に行っている。
エヴァンゲリオンはさすがに空いてるところが見つからないが、他は朝一とか夜のもので見に行っている。
声優や出演者の方の舞台挨拶が増えてきたので、それだけは混んでる中に嫁ぎ機をしてしまった。

ぶろぐ

ずっと読みたいなと思っていたけど電子版だと本読まないしなーと思っていたけど、秋葉原で書籍版を見つけたので買って読んでしまった。
とてもおもしろかったのでオススメしたいと思ってブログを書いた。

hihihiroro.hatenablog.com

「Engineers in VOYAGE - 事業をエンジニアリングする技術者たち」を読んだ

本が発売された頃から気になっていたが秋葉原書泉ブックタワーに行った際に、書籍で売っているのを見かけたので衝動買いをした。

本書は特定の技術や分野について書かれているわけではなく、VOYAGE GROUP にある 5 つの事業会社それぞれの事業を支えるシステムの開発、運用、改善といった内容について在籍するエンジニアへのインタビュー形式でのまとめになっている。
本書の目次は以下

第1章 fluct - 広告配信の舞台裏の技術者たち
第2章 Zucks - フルサイクル開発者の文化
第3章 VOYAGE MARKETING - 20年級大規模レガシーシステムとの戦い
第4章 VOYAGE Lighthouse Studio - 数十万記事のメディアをゼロから立ち上げる
第5章 サポーターズ - 事業の成長を止めない手段としてのシステム刷新
第6章 データサイエンス - エンジニアによるビジネスのための機械学習

事業の内容も開発時期も違うため、それぞれの事業で求められているものも目標も異なっている。本書ではそれぞれの現場でビジネスを発展させていくために、システム開発における意思決定と施策をどのように行ってきたかが成功だけではなく試行錯誤している姿も合わせて書かれている。
新規サービスを何を使って作るかワクワク考えるような内容があったり、昔からの技術負債と向き合わなくてはならなくなり試行錯誤する場面もでてくる。エンジニア歴の長さに関わらずこれなと頷く部分は沢山あると思う。

共通になっているなと思うことはエンジニアとビジネスの人たちの距離がとても近いことだった。ビジネスの人たちが開発速度が遅くなってないかとエンジニアたちが困っていることに気がつく場面があったり、エンジニアの人たちが自分たちが考えたサイコウのシステムを提供するわけではなくビジネスと話し合い、求められている機能、解決すべき課題を順々に実装をすすめていた。これが本書の副題になっている「事業をエンジニアリングする」という意味なのだろうか。

システムを作っていると自分たちが作っているものは良いものだ、自分たちがやりやすければユーザも使ってくれるんだと思ってしまう時があると思う*1。しかし正論を通したところで、お金が稼げない、誰も使ってくれない、使っている人が文句しか言ってないというものを作っても意味が無いのだ。
この辺りの感覚については社内の横断基盤の開発・運用を行っていてずっと思っている。自分たちのサイコウを詰め込んだところでつかわれなかったらただのお荷物になってしまう。そのようなことが起きないように、ビジネス側や仕様者と密接につながって開発を行っている本書を真似できればなと思った。

また、それ以外にもエンジニアにとって大切なサービスが止まらないために何をやるべきか考えていることも真似したいと思った。なんでも新しくするだけを考えるのではなく、止めないとめにどうすればよいかを考えることはとても重要だなと思った。そのためには古いシステムの延命も検討するなどエンジニアの中での優先度がしっかり定まっているのだろうなと思いながら読んだ。そしてそれらを実行するための腕力も身につけていきたい。

まとめ

  • 現場でどのように考えたかがわかりやすく書いてあるのでなりきった気分で読んでみるのが面白い
  • 自分たちのシステムってなんで開発・運用しているんだけって考える事が増えた
  • システム・サービスに関わる人皆と仲良くエンジニアリングしていきたい

*1:皆さんはどうか思わないが僕には思ってた時期があった

202105 振り返り

休みが長かったのに何かをやった気はしていない。
写経から抜け出せていないが、毎日Github にコミットをすることを以下の記事を読んで真似してみている。

blog-jp.richardimaoka.net

広い部屋に引っ越して、作業するところと寝るところを分けたいと考えている。
そのための家探しを始めたが広くするとさすがにお高くなるのでそれに合わせて給料も上がると嬉しいのになと考えている。
家探し、引っ越しまでを1ヶ月以内で終わらせたいなと頑張っている。

べんきょうかい

休みにあったので途中しか参加できなかった。それでも面白かった。

ほん

GW で時間があったので去年買った本や小説を読むことができた。
コミックは引き続き沢山読んでいる。面白い本が次々出てきて困ったもんだ。

えいが

1本も観に行くことなかった。早く落ち着いてもらいたいものだ。

ぶろぐ

話題になっていた本気になっていた本 を読んだ。
運用のお仕事も長くなってきたので勉強してみようと気になって読んだ。続きも出ているので読んでみる。

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

「運用設計の教科書」を読んだ

運用について教えてもらったり、勉強をしたりすることが今まであまりなかった。経験則でこういったことを考えたほうが良いとか、ここが危なそうなどの勘をきかせていることが多かった気がする。しかし、サービスが開発終わってからやっていることは運用と考えると開発期間よりも長く行うことなので学んでみようと思った。また、以下の文言に同意したことも読もうと思った理由になる。

IT業界で運用の仕事はあまり良いイメージがありません。決まった時間に手順に従って単純な作業をするだけ。関係者感の調整をしているだけ。そのせいで技術もスキルもあまりつかない・・・・・・。社会への貢献に反して、運用に対するマイナスイメージがつきまといます。本当はもっと価値のあることをしているのに。
- 運用設計の教科書 ~現場で困らないITサービスマネジメントの実践ノウハウ P.1

目次は以下。

1章 運用設計とは
2章 フェーズから考える運用設計
3章 運用業務のケーススタディ
4章 基盤運用のケーススタディ
5章 運用管理のケーススタディ

本書では運用をシステムを安定稼働させて効率的にサービスを提供することを目標としている。そして、運用設計はサービスの重要度に合わせて運用を最適化することと定義している。
ここで大事なのは

  • これをしないといけないというものは決まっていないこと
  • サービスによってやるべきレベルが変わること

上記なのかなと思っている。1年に1回しか必要ないシステムに対して、24時間365日止まったら困るシステムに対してはそれぞれ別の運用設計が必要になるのだろう。なので何かを真似すれば良いと考えるのではなく、それぞれに対しての正解を探し続けることが大事なのだろうと思う。

本書では運用を3つに分類している。

1. 業務運用 システムの業務に関する運用を指す。特に自動化することができなかった、人間がやるべき業務を指す。
2. 基盤運用 システムを維持するための基盤メンテナンスを指す。例えば、OSの定期アップデート、システム監視、不具合対応等。
3. 運用管理
運用に関わる人が守るべきルールと基準を決めること。システムによってルールが違うと利用者の利便性が下がる、運用者の負荷が上がる問題があるためできるだけルールを揃えることが大事。

また、運用設計をすることでの効果が5つ紹介されている。

1. 運用範囲の決定・・・どこまでが自分たちの運用範囲なのかわかる
2. サービスレベルの安定・・・システム停止時間を最小にできる
3. 属人化排除・・・スキルに大きく左右されない
4. サービス品質の安定・・・誰が作業を実施しても同じ結果が得られる
5. ドキュメントの可視化・・・修正対象のドキュメントが明確である

これを読んで自分のチームでは運用の分類をしっかりしていないなと思った。運用と一言でまとめて言っていて、それぞれに対しての自動化する範囲、ドキュメントをどこまで書くかなどをちゃんと決めてないなと反省した。
自動化しろ、ドキュメント書けとは言っているが年1回しかやらないような作業を1ヶ月かけて自動化するなどは無駄なのだろう。それぞれの作業についてやるべきことを決めるのは普段からやっている。
それではなく、やらなくてよいことを決めることが大事だろうなと思った。作業に見合うものなのかを考えながら作業していきたいなと思った。

また本書の中では開発フェーズによって作っておくべきドキュメントの話がされているのが面白かった。開発が終わってから、あとこれを運用しといてねだと運用者に対する負担も大きいと思うし、そもそも運用できるかこんなものというアプリケーション、ツールが出来上がることもあるだろう。
その点、僕が働いているチームでは設計の時点から運用者を巻き込んで運用ができるか、なにができていると運用が楽になるかを一緒に考えてくれている。これは今後もうまくやっていきたいなと思う。

あとがきにあったが、運用には正解がないのだろうなと思う。時代や環境によってやるべきことは変わるだろうし、運用者のスキルによってできるできないもあるだろう。それぞれの運用しているチームで何が良いのかをずっと考えていくしか無いなと思った。ただ、運用ってなんだろう?運用するときに考えなければいけないことはなんだろう?ということを体系的に読めたので良かった。

また、サービス開始後の運用は運用改善としての扱いがあるみたいなので著者の別書になる「運用改善の教科書」を読もうと思う。

まとめ

  • 自分の仕事の運用を分類分けしてみようと思った
  • 今できていることは継続していきたいと思った
  • 無駄にやりすぎてしまっていることを止めて他にやるべきことをやっていきたいなと思った

システム障害対応の教科書

システム障害対応の教科書

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

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

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

「ユニコーン企業のひみつ」を読んだ

気になっていた本を誕生日祝で頂いたので読んだ。
著者は「アジャイルサムライ」「初めての自動化テスト」のジョナサンさん。

ユニコーン企業

評価額10億ドル規模の企業ながら、スタートアップみたいに運営されている企業
例) Google, Amazon, Facebook, Spotify など

章立ては以下。

1章 スタートアップはどこが違うのか
2章 ミッションで目的を与える
3章 スクワッドに権限を与える
4章 トライブでスケールさせる
5章 ベットで方向を揃える
6章 テック企業で働くということ
7章 生産性向上に投資する
8章 データから学ぶ
9章 文化によって強くなる
10章 レベルを上げる:ゆきてかえりし物語

率直な感想はとても読みやすかった。イラストが多用されているし、文章もスラスラと読みすすめることができたので気がついたら読み終わっていた。
内容としてはSpotify での組織、チーム作りや仕事の進め方について具体的に著者が経験してきたことが書かれている。どこの会社でもやっていることではなくSpotify が今まで実践してきたことが書かれているのだと思った。本書を読んで真似すればどこでもうまくいくというものではないと思う。

訳者あとがきにあったが、本書の内容は執筆していた時期のSpotify のスナップショットであるらしい。本書で紹介されている組織だったらやることを次々変えているだろうから今も同じであることはなさそうだなと思った。Spotify がマネジメントする時や組織を作るときにこう考えているということがわかる気がする本だった。
スクワッド、トライブ、ギルド、チャプター、リリーストレインなど*1取り入れてみたい紹介が沢山されている。しかしこれらは上記のようにSpotify がその時必要だと思って考えて作ったものだと思うので、ただ真似すればよいわけではないのだろう。

読んでいてこのようなチームを作るのには以下が最低限必要だなと思った。

  1. 学習を続ける人を集める
  2. チームに対して権限を与える
  3. チームを信頼する

これらが満たされていれば、ミッションを与えられればそれを達成するための活動を行うだろうし、やりたいことを探してきて自発的に行動をすることも可能だろう。プロジェクトで仕事をしないっていうのもそう考えると自分は納得ができた。わざわざこの期間でこれをやれと指示する必要がないのだろう。

それ以外に自分が気になったのは生産性向上に投資するというところになる。
これらが大事なことだと分かっているのにできていないところが多いという話にすごく親近感を感じた。ビルドの自動化、トレーニングセッションの開催や基盤準備、監視ツールの作成などいつか必要だと思うものやそれがあれば良いのになというものにも積極的に時間をかけているのがとても羨ましいなと思った。

ちょっと話が変わるが最近思っていることに、アプリケーションの開発ではなく、インフラ開発、運用作業などは評価がされづらいと感じている。動いていると当たり前と扱われ、なにかエラーがでた時には反応をされる。あって当たり前だと思われているものはアプリケーションの開発と違くて、わかりやすい評価がされにくいなと思う。それでも、アプリケーションを動かすためにはインフラが必要だし、社内提供しているサービスなどは開発は止まって提供する運用だけずっと続いていることがある。それらが止まらないよう作り直したり、アップデートしたり、エラーになりそうな箇所を修正したりということを行っている。しかし、目に見える動きとしては変わっていないため評価はされづらいなよと思っている*2
ただ、本書では生産性向上についても取り組みをいろいろされているようなのでとてもおもしろく読んだ。この辺りの評価周りなどについてはもう少し詳しく知りたいなと思った。

まとめ

  • 自分たちができていることできてないことを見比べるのが楽しそうななと思った
  • 自分たちのいる意味、何を達成すべきなのかを考えてみようと思った
  • 最後はただの僕の愚痴になったw

初めての自動テスト ―Webシステムのための自動テスト基礎

初めての自動テスト ―Webシステムのための自動テスト基礎

  • 作者:Jonathan Rasmusson
  • 発売日: 2017/09/21
  • メディア: 単行本(ソフトカバー)

*1:それぞれの言葉の意味はとてもわかりやすく紹介されている。

*2:思っていること悩んでいることが多いので、この辺同じ意見の人と話し合いたい

「NVC 人と人との関係にいのちを吹き込む法」を読んだ

NVCとは、非暴力コミュニケーション(Non Violent Communication) という、人を思いやる気持ちを引き出せるようなコミュニケーションの方法の考案でである。

NVC のプロセス

  1. 観察。相手の行動について評価を交えることなく観察する。
  2. 感情。相手の行動を観察したときの自分の感情に注目する。
  3. 自分の感情の根底の見極め。自分が何を必要としているから自分のその感情が引き起こされているのか自覚する。
  4. 要求。自分の人生を豊かにするために要求する。

自分も他人も傷つけてしまうコミュニケーションとして、道徳を持ち出す、比較をする、責任回避をするなどの実例が紹介されていた。
これらのことがあると先入観や思い込みが先立ってしまい対立した意思疎通が起きてしまう。それを避けるため、一切の評価を抜いた事実だけの観察を述べ、その観察に対する自分の感情とニーズを述べて、自分の要求を伝えることが大切だと説明されている。
こうすることで、NVCでは相手に抵抗感を抱かせたり自分の感情を犠牲にすることなく、人を思いやるコミュニケーションができると説明されている。

この本を読んで思い出したのは、人に理解をされていないなと思うときは自分の考え、特に感情を共感されていないときだなと思った。
人に話をするときには自分の考えを極力含めず、事実を話すようにしようと心がけていたがそれだけでは駄目だということを思った。話し合いをするときや意見交換のときに事実だけ言っても意味がないが知識から話をしてしまうことが多かった。
話をする場所や関係によって変わるのだろう。

自分の考えや感情がうまく表現できない。どう思っているかを答えることなどが苦手である。そのため自分が何をしたいのか、したいと思ったことをうまく伝えることができないことを多々感じる。本書を参考に人との関係性だけではなく、自分自身のことをよく理解するためにもNVC をしっかり噛み締めてみようと思う。

まとめ

  • NVC のプロセスを実践してみようと思う
  • まずは他人にではなく自分の考えに対してやってみる
  • 自分みたいに悩んでいる人がいたら本書を推薦してみたいと思った