勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

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

Project Management Postmortem

趣味の情報システム障害状況ウォッチ。2017年後半のウォッチが飛んでいるのは自分自身とか所属組織が巻き込まれたとかではなく、単に忙しくなって忘れていたから。とはいえ現在も忙しいので個別事象のピックアップは省略。

過去に書いた関連記事は以下の通り。

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

2018年上半期（1～6月）は前年比で障害は多かったそうだ

2017年は月平均4件の障害だったものが、2018年前半は大きく増えて平均5.8件と躍進していたそうだ。聞いただけで胸が痛くなる。
ただしこのカウントは

  • 報道等でピックアップされた件数カウントなので、報道されていないトラブルはノーカウント
  • ヒューマンエラーなどもカウントされているので、システムそのものの品質についてどうこう言えるようなデータではない

という点に注意が必要ではある。

大ネタだけおさらい


こんな事も書かれてるよ

なお、このようなシステム統合とは問題が異なるが、来年5月には改元されることになっており、官民の多くのシステムは新元号への対応が必要である。報道によれば、新元号の公表は改元の1か月前を想定しているとのことであり、システムの変更に使える時間は非常に短い。1か月の短期間ですべてのシステムが改修を終えることは困難なため、一定期間は旧元号の利用も認められるようであるが、その間は新旧元号を用いるシステムが併存することになる。 システムが単独で運用されることはまれで、むしろ多くのシステムが相互に接続されて運用されるため、このような混在は問題をより複雑にすることが予想される。さらに、来年10月には消費税率の10%への引上げが予定されてい る。2014年4月に実施された8%への引上げの時にはシステムのトラブルが 7 件報道されており[松田 2014]、同様の障害が再発しないよう注意が必要である。いずれにしても、事前に十分な準備を行い、障害なく円滑な移行が行われることを期待する。

まぁ、仰る通りなのだけれども・・・

LeanとDevOpsの科学/Accelerate翻訳版が出るみたい

book

先日英語版で読んだAccelerateがさっそく翻訳されたようだ。なるほど、タイトルはこうなるのか・・・

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

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

Kindle版が出るのかは発売日まで不明、でも出そうだな～
出てました。というわけでリンクはKindle版に変更。

パフォーマンス分析に関するアンチパターン

Professional Engineer

いくつかの書籍に書かれたパフォーマンス分析に関するアンチパターンを整理してみた。ここに無いものでご存知のパターンがあればご教授いただきたい。アーキテクチャや組織のパターンはよく見るけど、対応手法に関するパターンってあんまり多くないのかも（もしくは単にアンテナ感度が悪いだけ？）

詳解 システム・パフォーマンス (Systems Performance: Enterprise and the Cloud)より

詳解 システム・パフォーマンス

詳解 システム・パフォーマンス

第2章 メソドロジでいくつかアンチパターンが紹介されている(アンチではないほうのパターンも)。
書籍の内容の一部は、以下の翻訳記事および元ネタ記事と同様と思われるので、書籍にあたる前に一読するのが良いかも。

Streetlight Anti-Method (街灯のアンチメソッド)

自分のよく知っている観察ツールや、インターネットで拾ってきた可観測性ツール、その他何でも適当な観察ツールを使って、何か明らかな問題が現れるかどうかをチェックしてパフォーマンス分析とする

このメソドロジは、次のたとえ話が示す街灯効果（streetlight effect）という観察結果のバイアスから命名されている。

ある晩、警察官は街灯の下で探しものをしている酔っぱらいを見て、何を探しているのかと尋ねる。酔っぱらいは鍵を失くしたという。警察官も見つけられず、酔っぱらいに尋ねる。「街灯の下のここで失くしたというのは確かなことなんですか？」 酔っぱらいは答える。「いいや、でもここは明かりの具合が一番いいからね」

詳解 システム・パフォーマンス

Random Change Anti-Method(ランダム変更アンチメソッド)

どこに問題があるかを適当に推測し、その問題が消えるまで適当に変更を加える。

Blame-Someone-Else Anti-Method(誰か他人のせいにするアンチメソッド)

  1. 自分に責任のないシステムまたは環境のコンポーネントを見つけてくる。
  2. そのコンポーネントに問題があるという仮説を立てる。
  3. そのコンポーネントに対して責任を負うチームに問題を丸投げする。
  4. 仮説の誤りが証明されたら、ステップ1 に戻る。

詳解 システム・パフォーマンス

Optimizing Java

Optimizing Java: Practical Techniques for Improving JVM Application Performance (English Edition)

Optimizing Java: Practical Techniques for Improving JVM Application Performance (English Edition)

Chapter 4. Performance Testing Patterns and Antipatternsでいろいろと紹介されている。

Distracted by Shiny

レガシーコードは掘り起こさず、新しい技術やテクノロジー部分からチューニングしようとする

Distracted by Simple

われわれが理解している部分から始めよう

Performance Tuning Wizard

天才、スーパーヒーローを雇用して対応する

Tuning by Folklore(民間伝承に基づくチューニング)

「マジック」設定パラメータをネットで探すことに熱中する

The Blame Donkey

分析せずに、特定のコンポーネントが原因だと決め付ける

Missing the Bigger Picture

全体像を把握する前に、アプリケーションの特定の部分のプロファイリングや変更に注力する

UAT Is My Desktop

本番環境と異なる環境で調査する

Production-Like Data Is Hard

本番環境と同等のデータを準備することは難しい

個人的なまとめ

結局のところ、環境やOSを含めたアーキテクチャの全体像をモデル化して計測を行い、仮説の構築と測定を繰り返すのが正しいと思われる。しかし全体像のモデル化が難しい。Linuxサーバであれば「詳解 システム・パフォーマンス」を参考にするのが良さそう。Winodwsサーバはどうだろう、手元で取り扱っていないので良いモデルがあるのかはちょっとわからない。

おまけ：開発者が間違った技術選択をし続ける理由

前述の「Optimizing Java」で紹介されていたブログポストが興味深いのでこちらもピックアップしておく

  • 理由#1：退屈
  • 理由#2：開発者の経歴書に追加するため (Résumé Padding)
  • 理由#3：同僚や上司からの圧力
  • 理由#4：技術理解の欠如
  • 理由#5：誤解／存在しない問題に対する対処

どれも困ったことだけど、気持ちはよくわかる。#1～#3が発生しないように気をつけたいけれども、どうしたものか。

おまけ：アンチパターンのたのしみ

主人公たちの失敗をオーバーに描くことは、喜劇の定石である。その意味で本書の読後感ならぬ読中感は、アメリカ製の上出来の喜劇映画を見ている思いがする。なにしろ、この本は一貫して笑える。
アンチパターン―ソフトウェア危篤患者の救出 訳者あとがき、より

アンチパターン―ソフトウェア危篤患者の救出

アンチパターン―ソフトウェア危篤患者の救出

最近チェックしている英語技術書（2018/11）

book safaribooksonline

Safaribooksonlineを個人で利用できるようにしたので（詳しくはこちら）時々面白そうな本が無いかチェックしている。最近チェックした本についてのまとめ。なお、どれも完読はしていない。

Seeking SRE

Seeking SRE: Conversations About Running Production Systems at Scale

Seeking SRE: Conversations About Running Production Systems at Scale

SRE本というとGoogle発の2冊が有名だが、本書は出自が異なり、SRECon Europeというコミニュティがきっかけで書かれたエッセイ集（一部はインタビュー）のようである。エッセイ集なので話題は多岐に渡っていて、テーマによってもちろん執筆者も異なる。
というわけで、タイトルなどを見ながらつまみ食い的に読めばよいと思う。

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

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

Technology Strategy Patterns

Technology Strategy Patterns: Architecture as Strategy (English Edition)

Technology Strategy Patterns: Architecture as Strategy (English Edition)

2018年のO'Reilly Software Architecture Conferenceで発表された次の資料をベースにした本。

いわゆるビジネス戦略コンサルティング会社が使うような戦略分析のメソッドをベースに、技術戦略を構築するフレームワークとパターンについて書かれているようだ。さわりの部分しか読んでいないが、MECEとかSWOTとか見慣れた分析メソッドも含まれている。

SIerさん的な観点で見ると企画段階にコンサル会社さんが入っていれば役割分担的にも無視してよさそうだが、実際は諸々の事情によりSIer側でビジネス分析を求められる事がある。そういったシチュエーションで使えるノウハウが載っていそうな期待あり。

なお本書の冒頭を流し読みしている中で次の本が紹介されていた。こちらも読みたい。

戦略の世界史(上) 戦争・政治・ビジネス 戦略の世界史 戦争・政治・ビジネス

戦略の世界史(上) 戦争・政治・ビジネス 戦略の世界史 戦争・政治・ビジネス

Fundamentals of Data Visualization

Fundamentals of Data Visualization: A Primer on Making Informative and Compelling Figures

Fundamentals of Data Visualization: A Primer on Making Informative and Compelling Figures

文字通りデータの視覚化に関する本。技術的にはRとggplot2で視覚化しているが、技術的な側面より視覚化に関する包括的な考え方や注意点について書かれているように見える。
この手の本としては古典としてタフテのThe Visual Display of Quantitative Informationが知られているが邦訳も電子版もなく、ちょっと人に見せてもらったのだけれども人力だけで読むのは相当骨が折れそうだ。

The Visual Display of Quantitative Information

The Visual Display of Quantitative Information

新Kindle Paperwhiteが良さそうな一方で5年前に買った旧機種が現役という問題

Kindle

新Kindle Papewhiteが発表された。順当に軽量化、高性能化されているだけでなく、ついに防水対応されたのでさすがにちょっと欲しくなっている

Kindle Paperwhite、電子書籍リーダー、防水機能搭載、Wi-Fi 、8GB(Newモデル)

Kindle Paperwhite、電子書籍リーダー、防水機能搭載、Wi-Fi 、8GB(Newモデル)

一方で、5年以上前に購入したKindle Paperwhiteが健在で現役、利用に支障が無かったりする。本当にコスパ高い端末だと思う

5年経過したKindle Paperwhiteの状態

購入した時の記事はこちら

で、購入してから5年4ヶ月くらい経過したわけなのだけれども、別に利用に支障もないし不満も特にないのだった。

  • 特にカバーなどはせず、丸裸で利用
  • 何度も落とした事があるけれども(特にベットから寝落ち、床下に落とすなど)、故障などは特になし。ボディに細かい傷はついたが気にならないレベル
  • バッテリーは購入当初に比べたらヘタってるのかもしれないけれど、気になるほど劣化している印象はない。1週間に1度くらい、気がついたら充電している
  • バックライトの劣化なども感じない(そもそも最高輝度にすることがないので、劣化に気付いていないだけかもしれない)
  • 最新モデルのほうが大容量だと思うが、コミックはあまり読まないし読み終わった本は適宜削除しているのであまり不満ではない
  • Kindleであればセールなどで話題の書籍が、10%-50%オフ(もしくはポイント還元)で購入できるので読書魔としては本当に助かる
  • 5年で通算500冊くらい読んでいる計算。十分に元をとった気がする

冒頭にも書いたけれども、コストパフォーマンス高い。優秀な端末だと思う

しかし防水機能は魅力的

最近(皮肉にもKindleで)「もうすぐ絶滅するという紙の書物について」を(やっぱりセールで半額で)購入して読んでいるのだけれども

もうすぐ絶滅するという紙の書物について

もうすぐ絶滅するという紙の書物について

そこで繰り返し語られている通り、やっぱり紙の書物はメディアとして優秀なのである

  • 安いコスト
  • 高い耐久性
  • 優秀な閲覧性
  • 軽量、コンパクト

まあ、そうですよね

一方で紙の書物の弱点のひとつは、水に弱いことである
今回の新モデルでは防水、短時間の水没にも耐えうるということなので、この弱点が克服されているのが非常に魅力的だ。

うーん、セールになったタイミングで購入するかなぁ〜。悩ましい

State of DevOps Reportより踏み込んだ考察本「Accelerate: The Science Behind Devops: Building and Scaling High Performing Technology Organizations」が面白い

book safaribooksonline

大分周回遅れなのだけれども、最近読んでいる「Accelerate: The Science Behind Devops: Building and Scaling High Performing Technology Organizations」がめっぽう面白い。なお以下にKindle本へのリンクを示すが、私はここに書いた手法で定額制の範囲内で読んでる。

Accelerate: The Science Behind Devops: Building and Scaling High Performing Technology Organizations

Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations

Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations

まだ途中までしか読んでいないのだけれども、物凄く雑に例えると「DevOps白書」みたいな本。DevOps白書としてはState of DevOps Reportというものが従来から存在するのだけれども、本書はそこから踏み込んだ分析と考察した結果が書かれている本である。なおState of DevOps Reportの分析メンバーと著者は一緒。

Puppet LabsのState of DevOps Report 2017が報告され、ハイパフォーマンスなITチームはより頻繁にデプロイメントを行い、より高速に障害のリカバリーを行なっていることが明らかになった。自動化、疎結合なアーキテクチャ、継続的デリバリーを促進するチームにより焦点が当てられている。変革的なリーダーシップとリーンな製品管理のプラクティスもハイパフォーマンスなチームの背後にある重要な鍵である。

で、Martin Fowlerが推薦文書いてるが、ベタ褒め。

So, as you may expect, I’m delighted that they’ve put this book into production, and I will be recommending it willy-nilly over the next few years.

基本的には「どうやったら開発パフォーマンスが向上するか」「(DevOps文脈における)どのような取り組みが開発パフォーマンス向上に意味があるのか」といったテーマについて書かれている本である。さまざまなファクター間の相関モデルはここ(注：PDF)などでも閲覧できるので、まずはちょっとチラ見してみると良いかもしれない。馴染みのある概念もあれば、ちょっと目新しいキーワードも現れている(例えば自分が不勉強なだけかもしれないが、Westrum Organization Cultureといった考え方は初見だった)。

この本の一番シビれるところは、ソフトウェア開発における開発パフォーマンスの定義、かもしれない。本書では、コード量やヴェロシティやソフトウェアの使用率といった、従来的な(アウトプットベースの)パフォーマンス測定方法は一切無視して、

  • デリバリの頻度
  • 修正のリードタイム
  • MTTR
  • 修正失敗率

という4つの指標を開発パフォーマンスのKPIとしているという点かもしれない。この指標についてはState of DevOps Report 2017のP.20~ IT performance & organizational performanceに書かれているものと一緒。もし興味があれば改めてReportを読んでみてもよいかも。この4つの指標は一見するとものすごい割り切りのような気もしたけれど、よく考えるとけっこう味のある組み合わせだ。4つの指標それぞれを同時に向上させるのはけっこう難しそうである。

そういえば小ネタとして、コード修正量が生産性指標として無意味である証明として1982年のApple Lisaの話がさらっと紹介されていて笑った。この話、前にどっかで読んだんだけど思い出せない。

「The Art of Monitoring」で紹介されてた時系列データ可視化のコツ

book safaribooksonline

先日読んだ「The Art of Monitoring」で紹介されていた時系列データ可視化の参考資料について調べたこと。Datadogの資料はすごく参考になる。

The Art of Monitoring (English Edition)

The Art of Monitoring (English Edition)

2.4 Visualization
We've drawn most of our ideas from Edward Tufte's The Visual Display of Quantitative Information and throughly recommend reading it to help you build good visualizations.
There's also a great post from the Datadog team on visualizing time-series data that is worth reading.

The Art of Monitoring (English Edition)

タフテの「The Visual Display of Quantitative Information」

The Visual Display of Quantitative Information

The Visual Display of Quantitative Information

訳書はなし、Kindle版もなし。いきなり購入する勇気は無いので、まずどのような内容なのかいろいろ調べてみたが、この分野のバイブル的な本のようだ。

「スティーブ・ジョブスに学ぶプレゼンのスキル」は、このブログの人気エントリーの一つだが、ことプレゼンに関して私が師と仰ぐのはEdward Tufteである。日本ではあまり名が売れていないようだが、米国では「データのプレゼン技法」に関しては第一人者で、本も何冊も書いているし、全米各地でセミナーも行なっている。 私自身も、一日セミナーに参加したことがあるが、膨大な量の実例を集めて、それぞれのどこが優れているか、どこがダメなのかを的確に分かりやすく説明してくれるTufteは、まさに「プレゼンの神」であった。

この記事は実際に手を動かし、コンピュータを使ってデータ可視化を行う人に向けて一般的なノウハウをお伝えする三回シリーズの最終回です。

この記事の前半でたくさん取り上げましたタフテの著作です。現在までに四冊の本を出しており、どれも技術詳細から独立した基本原則を学ぶのにはとても良い本だと思います。特にThe Visual Display of Quantitative Informationは古典中の古典とも言える本なので、一度お読みになることをおすすめします。現在は第二版が出ています。

後者の記事では、タフテの「The Visual Display of Quantitative Information」からの引用画像も多く、とても参考になる。

タフテの本、いつか読んでみたいなぁ。

Datadogの「Metric graphs 101」

こちらはモニタリングクラウドサービスを提供しているDatadogのブログポストで、とても参考になる。英語だけど機械翻訳でも割と読めるので詳細は以下のリンク先を参照のこと。

最後のアンチパターンは笑えるような、胸が痛いような。