「Building Microservices」6章までを読んだ #デッドライン読書会

未消化の積読技術書をデッドラインを決めて読んで感想をブログに書く企画（ざっくり）の第4回。今回は少し前に発売されたオライリーの「マイクロサービスアーキテクチャ」を2回に分けて読むことにしている。というわけで第6章まで読んだ感想など。

マイクロサービスアーキテクチャ

デッドライン読書会のルールは、以下参照

• 読書×締切ではじめる「デッドライン読書会」を始めました | 84zume Works

Building Microservices

さて、今回対象の書籍「マイクロサービスアーキテクチャ」だが、原題は「Building Microservices」である。著者のSam NewmanはThoughtWorksのエンジニアのようだ。
おそらく本書が初の著書で、続編としてEBookとして「What are microservices?」という短いテキストが公開されている。現在は続編として「Monolith to Microservices」という本を執筆しているようだ。

• What are microservices? [Book]
• Monolith to Microservices [Book]

Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith

他に、著者は異なるが「プロダクションレディマイクロサービス」という本も良いという話を聞いたことがあり気になっている。これは翻訳書もある。

プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化

あとは最近パターン本もいろいろ出版されている模様。

• Microservices Patterns: With examples in Java
• Microservice Patterns and Best Practices: Explore patterns like CQRS and event sourcing to create scalable, maintainable, and testable microservices

いずれも未読だけれども、ちょっと眺めてみたいと思っている。
米オライリーのSafariBooksOnlineに加入すればどれも定額サービス内で読めるので、いずれ読んでみたい。SafariBooksOnlineへの加入などについては以下の記事を参照。

• 英語技術書を機械翻訳で読みまくる方法 - 勘と経験と読経

なお、今回とりあげている「マイクロサービスアーキテクチャ」についても、原著の「Building Microservices」を英語と機械翻訳で読んでいる。

1章〜6章の感想

本書を読む以前の個人的な感覚として、『マイクロサービス「的」アーキテクチャ』は意図して作り出すというより、現代的な技術／プロダクトの活用や、様々な制約回避の結果生み出されるもの、という印象を持っていたのだけれども、ある部分ではその通りであるということが確認できた。
(実際、本書の3章、4章では一度モノシリックな設計をした上で段階的にマイクロサービス化していく方法が示されている。また設計手法はDDDの文脈で語られている)
一方でモノシリックなシステムのマイクロサービスへの移行は意外にも本書では多く語られていない印象がある(ストラングラーパターンの話とかは大変興味深いのだけれども)。このあたりは現在執筆中の続巻に期待ということだろうか。
ストラングラーパターンについて調べてみたら、以下の記事が興味深かった。

• ストラングラーパターン：段階的なシステム移行 – VELTRA Engineering – Medium

そして、構築した（もしくは構築する）マイクロサービスシステムの取り扱い方が5章〜9章のテーマのようだ。そして10章と11章が総論と今後に向けた問題提起だろうか。このあたりはまだ読んでいないので本記事としても後編で扱う予定。そして読み終わったら、前述の類書もいくつか読んでみたい。

参考

• 書籍「マイクロサービスアーキテクチャ」まとめ（前編） - Qiita

気になる洋書技術書をとりあえず斜め読み 2019/5

読んでみたい本が多すぎる。が、よく考えてみたら米oreillyのサービスに加入しているので何冊読んでも追加でお金はかからない（定額読み放題）。というわけで、目ぼしい未読の洋書技術書について、まず冒頭だけざっと読んでみた。現時点の気になる本リストから8冊を拾い読み。

Design It!

Design It! [Book]

• 序文
  • この本にはアジャイルソフトウェア開発についての言及がない。それは本書がアジャイルとアーキテクチャの優れた統合であるからだ（George Fairbanks／書籍「Just Enough Software Architecture」(2010)(邦訳なし)の著者）
• 斜め読み
  • パート1とパート2はアーキテクチャ構築の方法論と著者のアイデアについて語られている。各章では仮想プロジェクト「Project Lionheart」ケーススタディが挿入されており理解を深めやすくなっている。
  • パート3はアーキテクトのツールボックスとして、様々なプラクティスに関する説明となっている。プラクティスは例えば「共感マップ」のような、アジャイル開発で用いられるようなものも多数含まれていて興味深い。

個人的な期待度：★★★（ぜひ通読したい！）

Design It!: From Programmer to Software Architect (The Pragmatic Programmers) (English Edition)

Software Architecture in Practice, Third Edition

Software Architecture in Practice, Third Edition [Book]

• 第3版の序文
  • 第2版出版から10年が経過した。ビッグデータ、ソーシャルメディア、クラウドといった新たな要素を取り込んだ。
• 斜め読み
  • パート1はアーキテクチャについての概要説明。パート2以降で、アーキテクチャと品質属性、開発ライフサイクル、ビジネスとの関係について論じている。最後のパート5では新興技術におけるアーキテクチャについて論じている。
  • 興味深いのは各章の最後に「ディスカッション」という項目があること。おそらく本書は教室で利用することを想定されており、各章について受講者が議論することを想定していると思われる（ディスカッションについては著者からの所見はなく、抽象的な問いが提示されている。例えば「ソフトウェアアーキテクチャーは、概念的なアナロジーとして建物のアーキテクチャーとよく比較されます。その類推の強みは何ですか？」のような感じ）。

個人的な期待度：★（うーん、この本はいったんパスかなぁ）

Software Architecture in Practice: Software Architect Practice_c3 (SEI Series in Software Engineering) (English Edition)

Software Architecture Patterns

Software Architecture Patterns [Book]

• はじめに
  • アーキテクチャの決定なく実装を開始するのは一般的によくあることだが、これは往々にして「巨大な泥団子」のアンチパターンにはまる。
  • アーキテクトは、常にアーキテクチャについて判断決定し正当化する必要がある。本書は正当化するための情報を提供するものである。
• 斜め読み
  • 本書は主に以下のアーキテクチャについて説明している。
    • 階層型
    • イベント駆動型
    • マイクロカーネル
    • マイクロサービス
    • Space-Based Architecture (日本語だと何ていうのがメジャーなんだろう)

個人的な期待度：★★（Building Microservice読み終わってから考える）

Designing Data-Intensive Applications

Designing Data-Intensive Applications [Book]

• 序文
  • 過去10年の技術的な発展で、計算集約型アーキテクチャと対比的なデータ集約型アプリケーションの構築が可能となった。
  • この領域は流行語で埋め尽くされているが、優れたアプリケーションを構築するためにはさまざまなテクノロジとそのトレードオフについて技術的に正確かつ正確に理解する必要がある。
• 斜め読み
  • 斜め読み程度では読みきれない・・・
  • 参考文献のリンク集：https://github.com/ept/ddia-references
  • このリポジトリにファンタジー小説に付録しているような各テーマの地図があった。これ日本語版には翻訳されたものがついているのかなー。https://github.com/ept/ddia-references/blob/master/ddia-poster.jpg しかし広大すぎる。

Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems (English Edition)

データ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理

個人的な期待度：★★（訳書が出版されてから出てくるであろう書評を見てみたい）

Learning Chaos Engineering

Learning Chaos Engineering [Book]

• 序文
  • 本書はカオスエンジニアリングの実践者向けの本である。Chaos Toolkitを使って Chaos Engineeringするための実用ガイドとなっている。
• 斜め読み
  • 第1章はカオスエンジニアリングの概要、第2章からは具体的なChaos Toolkit、そして使い方の説明になっている。

Learning Chaos Engineering: Discovering and Overcoming System Weaknesses Through Experimentation

個人的な期待度：★（ツール中心の説明なので、後回し）

Monolith to Microservices

Monolith to Microservices [Book]

• 序文はまだない（これから追加されるかも）
• 斜め読み
  • Building Microservicesの著者によるモノリスシステムのマイクロサービスへの移行、をテーマに書かれている本となっている。
  • 段階的な移行を前提として、移行するためのテクニックなどについて書かれている。

Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith

個人的な期待度：★（まだアーリーリリースなので、もう少し執筆が進んでから再確認したい）

Release It!, 2nd Edition

Release It!, 2nd Edition [Book]

• 初版は邦訳されている。ずいぶん前の本だが非常に有用だった印象あり。
• 序文
  • しびれる

この本では、現実世界の悪臭と悩みのために、ソフトウェア、特に分散システムを設計、設計、構築する方法を検討します。あなたはクレイジーで予測不可能なことをする非論理的なユーザの軍隊に備えるでしょう。あなたがリリースした瞬間からあなたのソフトウェアは攻撃を受けるでしょう。それは、フラッシュモブの台風や、しっかりと固定されていないIoTトースターオーブンによるDDoS攻撃の圧迫圧力に耐える必要があります。テストに失敗したソフトウェアを詳しく調べて、ソフトウェアが現実の世界との接触に耐えられるようにする方法を見つけます。

• 斜め読み
  • 初版と二版の目次を並べてみてみると、「第1部 安定性」はだいたい同じ。アンチパターンとパターンは増えている感じ。
  • 第2部以降は全面改定といって良いくらい手が入っている。章構成が全然違う。単に順序が変わっただけではなさそうだ。

Release It!: Design and Deploy Production-Ready Software (English Edition)

個人的な期待度：★★★（初版がとても良かったので、ぜひ読みたい）

Antifragile Systems and Teams

Antifragile Systems and Teams [Book]

• 無料のEBookのようだ（Kindle版は無料になっている）
• 薄い本のようなので、どこかで時間ができたらさっさと読むのがよさそう。

個人的な期待度：★★★（薄いので近日中に読み切る）

今回はここまで、来月またどこかで棚卸しをしよう

「業務デザインの発想法」を読んだ #デッドライン読書会

未消化の積読技術書をデッドラインを決めて読んで感想をブログに書く企画（ざっくり）の第3回。今回は発売されたばかりの「業務デザインの発想法」を課題図書に選定。読んでみた。

デッドライン読書会のルールは、以下参照

• 読書×締切ではじめる「デッドライン読書会」を始めました | 84zume Works

業務デザインの発想法?「仕組み」と「仕掛け」で最高のオペレーションを創る

わりと無かった業務デザインに関する本

「業務デザインの発想法」はタイトル通り、業務デザイン（業務設計）に関する本である。思い返すと業務デザインに特化した良書というのはあまり心当たりがないので、そういう意味では貴重なノウハウが詰まった本という気がする。

業務デザイン関連というと、ビジネスプロセスモデリング関連の書籍をこれまでは割と参考にしていた。たとえば古典（かつ絶版本）だけれども

ユースケース実践ガイド―効果的なユースケースの書き方 (OOP Foundations)

上流工程UMLモデリング

あと

要求開発~価値ある要求を導き出すプロセスとモデリング

あたりが良い本であった印象がある。ただ、これらの本はいずれもソフトウェア開発における開発対象の分析がメインの題材であり、いっぽうで業務デザインという意味では、

• 新規業務をどのような組織で遂行するか（業務体制の検討）
• 新規業務にどうやって移行するか（業務移行の検討）
• 新規業務開始後の運営をどうするか（業務運営の検討）

あたりも必要になるが、いずれも割と王道的なやり方・正攻法はなく、毎回工夫しながら乗り越えてきた気がする。そもそもソフトウェア開発エンジニアとして「業務設計」そのものに関わる頻度というのも多くなかったので、なんとかなってきた。
いっぽうで、RPAのような新しい技術による業務見直しや改善、BPRの機会はどんどん増えていくと思われる。その際には、本書を教科書のように使って効率的に業務設計ができるようになるだろう。

本書のカバー範囲と感想など

開発系ITエンジニアの視点で読みながらいくつか感想などを列挙してみた。

• 第1章 「何を」「どのように」提供するか決める ～業務設計／システム設計
  • ITシステム開発の文脈で言えば、業務要件定義に分類されるタスク。
  • ちょっと気になったのは、コンプライアンスやライセンス関連の記載がほとんどないところ。いつも重要になるわけではないのだけれども、設計した業務が法制度上問題ないかとか、商標や特許侵害していないかといった観点はあるような気がする。まあ、対象業務の規模や内容によるけれども。
  • 運用組織設計やリソース計画は（エンジニアとしては）割とお客様に担当いただく事が多いのだけれども、内容によっては（例えば新規業務部署を設立するとか）なかなか確定できないので、制約を整理して未決のまま設計をしたりすることもある。プロジェクトマネジメントの話だけれども、リスク管理が重要なエリアだと思う。

• 第2章 業務のおはようからおやすみまでを想定する ～ライフサイクルマネジメント
  • ITシステム開発の文脈で言えば、保守運用設計などと呼んだりするタスク。
  • 割と検討を後回しにしがちで、あとで死ぬやつ。

• 第3章 ステークホルダーを巻き込む ～コミュニケーション設計
  • ここは個人的には新鮮な内容だった。
  • ソーシャル時代の世相を反映しているような内容で興味深い。
  • 自分がやる場合には、Business Model Canvasあたりを活用しそう。
    • ビジネスモデル・ジェネレーション ビジネスモデル設計書

• 第4章 あたりまえの業務を，あたりまえに提供できるようにする ～オペレーションマネジメント
  • 戻って第2章と一緒に、保守運用設計に含めて考える事が多い気がする。もしくは、いったん実施した保守運用設計をベースに運用初年度の具体的な計画を立てる時に考えるようなイメージ。

• 第5章 業務の価値を高める ～付加価値向上
• 第6章 人と組織を継続的に成長させる ～環境セットアップ／ブランドマネジメント
  • 組織設計といったカテゴリの内容。残念ながら、SIerのエンジニア目線だとちょっと縁遠いというか、ここまで踏み込むことはあまり無い印象。

ちょっと残念だったところ

本書の一番良い点は、割と広範囲に業務デザイン周辺のテーマを総ざらいしている点なのだけれども、一方で個々の検討事項の分析の方法やアウトプットの定義までは踏み込んでいないところはちょっと残念。
例えば、業務設計の成果物やドキュメントはどのように定義すべきか（1-8章でラインナッップまでは提示されている）などである。
もしかすると、このあたりを補完する続編の構想があるのかもしれない（最近よくあるビジネス小説書形式とか）。

あと、私はKindle版で本書を読んだのだけれども巻末の索引が単なる用語の羅列になっており無リンクなのは、意図したものなのだろうか疑問である。可能であればアップデートで訂正いただきたいものだ。

Tail Latencyに関する論文読み

Misreading ChatのPodcastでTail Latencyに関する論文の紹介がされていて非常に興味深かったので、自分でも紹介されている論文を読んでみたという話。Misreading Chat Podcastのほうが的確な要約になっているので興味があればまず視聴するのがおすすめ。

• Episode 54 – Tales of the Tail – Misreading Chat

The Tail at Scale

米国計算機学会の機関紙Communications of the ACMの Feb/2013に掲載された記事。

• The Tail at Scale | February 2013 | Communications of the ACM ACM会員でないと全文参照できないかも。
• The Tail at Scale 同じ記事のPDF版。全文参照可能。

要点

• 大規模で複雑な分散システムでは、稀なパフォーマンスの低下が全体のパフォーマンス低下に繋がる事がある。
• 大規模システムではレイテンシ低下の原因を完全に除去することは難しい。
• 障害許容(フォールトトレラント)設計と同様に、テールレイテンシー許容設計をすることで、全体のパフォーマンス低下を対策することができる。

テールレイテンシーのよくある原因

• マシン上の共有リソース(CPUコア、キャッシュ、メモリ、ネットワーク)
• バックグラウンドデーモン
• グローバルリソース(ネットワークスイッチや共有ファイルシステム)
• メンテナンスのバックグラウンドアクティビティ(分散ファイルシステムでのデータ再構築、定期的なログ圧縮、ガベージコレクション)
• 中間サーバやネットワークスイッチにおけるキューイング
• ハードウェアによる制限（パワーリミット、電源管理、SSDのガベージコレクション等）

並列処理によってテールレイテンシーの問題は増幅される

• ユーザ要求を100台、1000台といった規模で分散処理する場合、1%, 0.1%の処理遅延が全体のパフォーマンスを悪化させる。

対策

• Hedged requests。同じ要求を複数のレプリカに連携、最速の応答を採用する。その後未処理の要求は取消す。
• Tied-Request。Hedged requestsで発生する無駄な処理を減らすためにキューに入れて処理をする。
• Micro-partitions。細分化する。
• Selective replication。 負荷の高い処理を優先的にレプリケーションする。
• Latency-induced probation。遅いマシンを隔離する。
• 最良の結果を返すのではなく、十分に良い結果で応答する。
• カナリア要求。いくつかの要求の応答時間が短いことを確認してから、残処理を実施する。

Tales of the Tail: Hardware, OS, and Application-level Sources of Tail Latency

• Tales of the Tail: Hardware, OS, and Application-level Sources of Tail Latency(PDF)

要点

• マルチコアマシンで実行されているハイスループットサーバーで、ハードウェア、OS、およびアプリケーションレベルでテールレイテンシが悪化する原因を探る。
• 予め作成した処理時間予想モデルに対して、Linuxサーバ（null RPCサービス、Memcached、およびNginx）で実測した上で検知されたテールレイテンシの原因を調査する。
• テールレイテンシの主要な原因は以下の通り
  • バックグラウンドプロセスからの干渉
  • 不適切なスケジューリング
  • 割り込みルーティング
  • CPUの省電力機能
  • NUMAの影響
• これらの要因を排除するとテールレイテンシの改善が図れる
• スループット、エネルギー、テールレイテンシの間にトレードオフがある

テールレイテンシーの原因

原因	理想値との乖離の理由	対策例	関係するトレードオフ
バックグラウンドプロセス	干渉によるスケジュール遅延	優先順位をRTにするか、専用コアに割当	RT化は他タスクの割当を阻害する可能性。専用コアはタスクアイドル時にシステム利用率を下げる可能性がある
Non-FIFO Scheduling	スレッドが順序どおりにスケジュールされていない	RTなどのFIFOスケジューラを使う	スケジューラの変更は全体の優先順位に影響する
並列アーキテクチャ	TCP接続を静的に分解するとワーカー別にキューが生成される	UDPイベント駆動型、またはスレッド毎のTCP接続アーキテクチャに変更する	UDP化は信頼性低下、スレッド毎のTCP接続はスループット低下となる
割込処理	コンテキストスイッチと、FIFO順序喪失	割込処理専用のコアを持つ	割込用コアの稼働率が低いとスループットが低下する可能性がある
NUMA Effects	NUMAノード間のメモリアクセスとキャッシュコヒーレンシプロトコルによる処理時間の増加	NUMAノードごとにプロセスを実行	複数キューによるレイテンシの発生、インスタンス間の負荷分散の問題が発生する可能性がある
Power Saving	CPUアイドル状態からの復帰時間	CPUの低電力制御をOFFにする	電力使用量の増加

ここまで読んでちょっと調べていて気づいたんだけど、論文ではなくてプレゼンテーションスライドも公開されているようだ。

• Tales of the Tail: Hardware, OS, and Application-level Sources of Tail Latency(Slides/PDF)

こっちを見たほうが断然わかりやすい印象。

もうちょっと関連論文を見てみようかと思い始めたところ。

Effective DevOps 第Ⅴ章～第Ⅵ章を読んだ #デッドライン読書会

未消化の積読技術書をデッドラインを決めて読んで感想をブログに書く企画（ざっくり）の第2回。
前回記事はこちら

• Effective DevOps 第Ⅰ章～第Ⅳ章を読んだ #デッドライン読書会 - 勘と経験と読経

ルールはこのあたり

• 読書×締切ではじめる「デッドライン読書会」を始めました | 84zume Works

というわけで、Effective DevOps ―4本柱による持続可能な組織文化の育て方の後半戦を読みきった感想也。

Effective DevOps ―4本柱による持続可能な組織文化の育て方

DevOpsは日本に定着するのか？

感想なのにのっけからこのような書出しになってしまうのだけれども、本書の後半の主要なメッセージは「DevOpsは文化である」だと理解している。そして文化である以上、この文化を広げていくためには知識やツールなどのノウハウだけでなく、

• ストーリーの共有
• カンファレンスやコミュニティ、ミートアップを通じた情報共有

などが重要である、とある。

これを読んで、ううむ、と唸ってしまった。
これは日本国内で定着するのに、時間がかかりそうだ。

思い返してみると、現在主流化しつつあるアジャイル開発も、最初は文化運動（しかも、ある種のカウンターカルチャー的なもの）だった。「アジャイルソフトウェア開発宣言」が発表されたのが2001年で、そこから実に18年が経過しているのである。しかも、アジャイルソフトウェア開発宣言そのものが広く行き渡った事によってアジャイル開発が拡散したのではなく、様々なツールと開発方法論が整備されて、やっと広がったのではなかったか。

DevOpsの考え方やアプローチは正しいと思うし、好みでもあるのだけれども、改めて「DevOpsは文化だ」と言い切ってしまうのは、理解は出来るが残念でもある。もしくはまだ黎明期であると考えるべきなのだろうか。

というのが、本書の後半を読んだ率直な感想である。少なくとも本書は気軽に初学者には進めにくいし、上司に提言する際に活用する本でも無い（スタートアップや小規模組織では別かもしれない）という印象である。

落ち穂拾い

後半（第Ⅴ章以降）で興味深かった話について

第Ｖ部　スケーリング

DevOps組織の構築と成長に関する論点が整理されている。
特に興味深いのは、英国のGovernment Digital Service（GDS）という組織および小売大手のTargetの事例である。
GDSの事例は首相官邸にいい感じのサマリー資料があったのであわせて紹介しておく。

• デジタル政府 英国の事例(PDF)
• 「「英国（GOV.UK）」のデジタルサービス改革 －住民・民間と一体となった政府デジタル戦略の推進－」 | 株式会社オージス総研

TargetについてはRedHatでも記事が出ているようだ。

• TargetのCIOが説明する、大規模小売業におけるDevOpsの実際 | RED HAT OPENEYE -レッドハットの情報ポータル

内容とは直接的に関係しないが、比喩表現として以下が面白かった。

• ゾンビプロジェクトと、ヴァンパイアプロジェクト
  • 改善を阻害するプロジェクトの例。
• たわごとの傘（shit umbrella）と、たわごとファネル（shit funnel）
  • Google/GMailのプロダクトマネージャ Todd Jacksonの発言 “You can either be a shit funnel or a shit umbrella.” に由来するそうだ。
    • Shit Umbrella売ってるぞ。When shit hits the fan – Go Weekly Insights – Medium

第Ⅵ部　devops文化への架け橋

18章　devops文化への架け橋:人と人のつながりを育てる、で触れられている「文化的負債」の話が興味深かった。
採用や解雇、不適切なルールや組織階層の問題などに関してである。このワードはDevOps界隈では昔からある議論のようだ。

• Don’t Let Cultural Debt Bring Down Your Business - DevOps.com

さて、84zumeさんはどんな感想だったのだろうか。意見交換が楽しみだ。

• デッドライン読書会#02「Effective DevOps（後半）」感想文 | 84zume Works

情報システムの障害状況ウォッチ（2018年後半）

趣味の情報システム障害状況ウォッチ。前回に引き続き、今回も駆け足で確認。

元ネタはこちら。みんな見たほうが良いよ！

• 情報システムの障害状況一覧：IPA 独立行政法人 情報処理推進機構

2018年後半（7～12月）の傾向

• 2018年前半はかなりハイペースで障害が推移（月平均5.8件）していたが、後半は若干スピードダウンして月平均5.2件のペースにダウン。通年では月平均5.5件の水準となったそうだ。とはいえ2017年の月平均が4件なのでトラブルの多い年だったことにはかわりない。
• 気づかなかったが前回集計からローカルニュース中心に報道された自治体などのトラブルを別カウントするようになったようだ（この障害は主要分析のカウントには含まない）。

主要なトラブルなど

というわけで、いまさらだけれど2018年後半のトラブルのおさらい。こんなことありましたね。

ファーストサーバ Zenlogic全停止事故

• 発生は6月だけれども、解消に時間を要した事例。Twitterが阿鼻叫喚だったのが懐かしい。
• 本障害の概要と原因についてのご報告 ｜Zenlogicサポートサイト[ファーストサーバ]
• ファーストサーバ - Wikipedia

ソフトバンク 大規模通信障害

• 12月6日に発生したもの。自分はソフトバンクユーザでなかったのでまったく気づかなかったのだった。一方で同じ原因と思われる通信障害は海外のモバイルキャリアでも同時に発生したようで、海外の同僚に連絡がとりにくくなったりしていた。
• ソフトバンク、通信障害の原因特定に2時間15分、脆弱性を露呈 - BCN＋R
• 「エリクソン製への依存を見直す」 ソフトバンク、通信障害の再発防止策を発表 LTE設備はマルチベンダー化 - ITmedia NEWS

東京証券取引所 システム障害

• 10月6日に発生したもの。めちゃくちゃ詳しく整理されている方がいる！
• 2018年10月に発生した東京証券取引所のシステム障害についてまとめてみた - piyolog
• 東証システム障害の深層、証券会社の明暗分けた縮退運用 | 日経 xTECH（クロステック） （有料記事）

病院の電子カルテシステムがランサムウェアに感染

• 10月16日に発生したもの。感染しただけでなく、バックアップ装置にテープが装填されていないという凡ミスでダメージ拡大。
• 悪質ランサムウェアでシステムがダウン！ どうすればいい？ ――専門家が語る“意外な対処法” (1/3) - ITmedia エンタープライズ
• http://www.city.uda.nara.jp/udacity-hp/oshirase/change-info/documents/press-release.pdf

雑感

• 2019年は元号変更や消費税率変更でいろいろありそう。
• 他にはシステム更改の増加トレンドもある。いろいろ過去の闇が掘り返されて明るみとなるようなトラブルも今後増えていくのではないかと予測。
  • DXレポート ～ITシステム「2025年の崖」克服とDXの本格的な展開～（METI/経済産業省）

これまでのウォッチ履歴

• 軽めに情報システムの障害状況ウォッチ（2018年前半） - 勘と経験と読経
• 情報システムの障害状況ウォッチ（2017年前半） - 勘と経験と読経
• 日経コンピュータ2017/8/3号特集「変わるITトラブル」を読んだ - 勘と経験と読経
• 情報システムの障害状況ウォッチ（2016年後半） - 勘と経験と読経
• 情報システムの障害状況ウォッチ（2016年前半） - 勘と経験と読経
• 情報システムの障害状況ウォッチ（2015年後半）、ポストモーテム - 勘と経験と読経
• 情報システムの障害状況（2015年前半）あるいは検死解剖 - 勘と経験と読経

システム障害はなぜ二度起きたか　みずほ、12年の教訓（日経BP Next ICT選書）

システムはなぜダウンするのか

Effective DevOps 第Ⅰ章～第Ⅳ章を読んだ #デッドライン読書会

技術書の積読が一向に減らない。世の中的には積読合宿で消化したり、ABDという読書手法で団体戦で消化する方法もあるようだが自分はあくまで自分自身で消化したい派である。というわけで知人と一緒にデッドライン（締切り）を設定して積読に立ち向かうことにした。第一弾としてEffective DevOpsを読んでいる。ボリュームがあるので前半と後半に分けていて、今回は2週間で前半部まで読んだ。というわけで本記事は前半の感想です。

Effective DevOps ―4本柱による持続可能な組織文化の育て方

DevOps関連書籍と、Effective DevOps

流行りのキーワードということもあり、DevOps本はいろいろと発売されている。これまでに自分でチェックした本は以下の通りである。

The DevOps　逆転だ！究極の継続的デリバリー

2014年に翻訳された本。ゴールドラットのThe Goalのような小説仕立てでDevOpsを紹介している。非常に面白いのだけれども、DevOpsをまったく知らない人向けな印象。なお米国流のシステム開発の文脈で語られているので日本的ソフトウェア開発との文化的違いも気になる。ある意味、経営層やマネージャ向けの本と言えるだろうか。残念ながら日本では刺さりにくそう。

DevOps教科書

2016年に翻訳された本。割とアーキテクチャ的な視点でDevOpsが語られているのが特徴。今あらためて読んでみると、DevOpsの文化的側面はほとんど触れていないのでびっくりする。一方でDevOpsを実現するアーキテクチャという観点での深掘りは非常に参考になる。

The DevOps ハンドブック 理論・原則・実践のすべて

2017年に翻訳された本であり、 The DevOps　逆転だ！究極の継続的デリバリーの続編でもある。前作とは一転してガイドブック／テクニック集な位置づけとなっており、現時点で最も教科書的に扱える書籍である。割とよく読み返している。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

2018年の翻訳本。タイトルどおりDevOpsを扱った本ではなく、SREについての本だが同書内でも「SREはDevOpsに拡張を加えたものと考えられる」と書かれている通り、DevOps的な文脈で読むこともできる。ただ本書はあくまでGoogleのSREに関する論文集であるため、DevOpsの参考書としては相当ハードルが高いと思う。

LeanとDevOpsの科学［Accelerate］ テクノロジーの戦略的活用が組織変革を加速する impress top gearシリーズ

2018年の翻訳本。DevOpsの解説書というより、毎年発表される「DevOps Status Report」の過程で得られたデータを下に、何をすれば開発スピードが改善されるかについて書かれている。DevOpsをさらに突き進むために、もしくは評価するために読むと良い書籍。

そして「Effective DevOps ―4本柱による持続可能な組織文化の育て方」

で、やっと本題。本書はどのような位置づけにあたるのだろうか。
前半しか読んでいないけれども、現時点の印象は

• DevOpsを進めながら突き当たる課題について考えるきっかけを与えてくれるエッセイ集
• プロセスとしてのDevOps導入時（輸入時）に抜け落ちてしまうカルチャー的な部分を補完する本

である。
というわけで、本書はDevOpsを学ぶ本ではなく、実践している人が読むべき本というのが前半を読んだ感想だ。

Effective DevOps 前半の感想

さて、Effective DevOps 第Ⅰ章～第Ⅳ章の感想である。なお実は私は翻訳本ではなく原著をベースに読んでいるので引用部部は訳書とは異なるかもしれない(そして誤訳しているかもしれない)点には注意いただきたい。

ロッククライミングの例え(2章 DevOpsとは何か)

DevOpsの説明でロッククライミングとの類似性が示されているところでオッと思った。確かにわかりやすい。この話は以下のブログ記事が元ネタっぽい。

• Climbing & DevOps: Rocking the Fear - VictorOps

DevOpsとITIL(4章 基本的な用語と概念)

4章では関連する方法論とDevOpsの関係について書かれているが、ITILについての触れ方は興味深い。

（ITアナリスト兼コンサルタントのStephen） Mann氏はITILはプロアクティブではなく反応的であることが多いと述べています。そのため、ITILを使用している組織は、より積極的な計画と顧客重視を実践に追加する方法を検討すべきです

DevOpsとITILの関係についてはDevOps教科書やSRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチームでも軽く触れられているが、上記のような見方までは提示されていない。

アンチパターンとしての根本原因分析（RCA）(5章 devopsに対する誤解とアンチパターン)

DevOps本によくある項目が「DevOpsに対する誤解」である。例えばSRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチームとEffective DevOps ―4本柱による持続可能な組織文化の育て方で比較してみるとこんな感じ。

• SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム (イントロダクション)
  • devopsは、スタートアップだけにあてはまる
  • devopsはアジャイルを駆逐する
  • devopsはITILと両立しない
  • devopsは情報セキュリティやコンプライアンスと両立しない
  • devopsはIT運用の廃止、"NoOps"という意味だ
  • devopsは、単なる"Infrastructure As Code"あるいはオートメーションである
  • devopsは、オープンソースソフトウェア専用だ

• Effective DevOps ―4本柱による持続可能な組織文化の育て方 (5章)
  • devopsに関係があるのは開発者とシステム管理者だけだ
  • devopsはチームである
  • devopsは肩書だ
  • devopsはウェブ系のスタートアップだけの問題だ
  • devopsには認定資格が必要だ
  • devopsとは、半分の人員ですべての仕事をすることだ
  • devopsには「正しい方法」（または「間違った方法」）がある
  • devopsを取り入れるためには X週間 /Xか月かかる
  • devopsはツールの問題だ
  • devopsとは自動化のことだ
  • devopsは一時的な流行だ

ラインナップの重複と差異が両書の違いを表しているようで面白い。

一方でEffective DevOpsにはアンチパターンに関する章もある。その中で根本原因分析（RCA）を取り上げているのが面白い。

根本原因分析には、システムが線形的に失敗する（または成功する）という暗黙の前提があります。これは、十分に複雑なシステムには当てはまりません

これはDevOpsに固有な話題ではなく、近年の複雑化するソフトウェアにおける重要なポイントを指摘していると思う。一方で、特に国内ソフトウエア開発のプラクティスでは類似の「なぜなに分析」が障害分析手法／品質改善手法として定着しているわけで、この使い方は今後見直すべきポイントの一つだろう。

6章 効果的なdevopsのための4本柱

おそらく本書の肝となるのがこの4本柱の概念である。すなわち

• Collaboration：開発チームと運用チームの協力
• Affinity：チーム間の関係を構築し、お互いに学び、目標を達成する
• Tools：アクセサレーター
• Scaling：成長・成熟および縮小の考慮

である。特にAffinityはこれまでのDevOps本ではあまり取り扱われていない(はずの)テーマだ。

9章 アフィニティ:個人からチームへ

で、アフィニティの話である。本章では個人間、個人とチーム、そしてコミュニティとの親和性（アフィニティ）について語られていて、個人的には本書の前半部で最も学びの多かった章だ。本書ではDevOpsから始まる信頼関係を組織レベルから業界レベルに広げ、革新するためにどうするかまで大きなスコープについて語られている。
なお、組織レベルの信頼性の問題は医療分野における安全確保のために色々と研究されてきているらしい。→Pathways for Patient Safety: Working as a Team(PDF) (この記事はちゃんと読めていないので、あとで改めて取り上げたい)

• チーム間の対立や利益相反をどうするか
• コミュニティとの情報共有と企業間の競争をどう考えるか(共有しすぎると競争力が弱まるのでは？)
• 特定の個人の言動がアフィニティを破壊する(いわゆるBrilliant Jerks問題)
• 妨害的なチームの存在の対処

などなど興味が尽きない。
本書では割とさらっと触れられている程度である。個人的に、もう少し深掘りしてみたい。

今後の予定

@84zume さんが同じデッドラインで読書中なので、別途感想戦を実施予定。

• デッドライン読書会#01「Effective DevOps（前半）」感想文 | 84zume Works

その後、4/2～4/15で本書の後半戦を読む予定である。
その次に読む本は現時点では未定。このあたりはどうかなぁ。

• 分散システムデザインパターン ―コンテナを使ったスケーラブルなサービスの設計
• 巨大システム　失敗の本質―「組織の壊滅的失敗」を防ぐたった一つの方法
• 大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法
• 進化的アーキテクチャ ―絶え間ない変化を支える
• マイクロサービスアーキテクチャ