勘と経験と読経

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

新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のブログポストで、とても参考になる。英語だけど機械翻訳でも割と読めるので詳細は以下のリンク先を参照のこと。

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

DevOps的な非機能要件（運用要件）リスト

book Professional Engineer

The DevOps Handbookで紹介されていた

を読んだら面白かったというメモ。国内ではあんまり取り上げられていないような気もする（もしくは私が不勉強で知らないだけ？）

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

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

開発部門が下流の作業の状況をフォローし、本番インシデントの解決の作業に参加すれば、アプリケーションは次第に運用にとってよい設計になっていく。さらに、スピーディなフリーとデプロイのしやすさを正面から意識してコードやアプリケーションを設計するようになると、すべての本番サービスに組み込みたいと思う一連の非機能要件が見つかる。
これらの非機能要件を実装すれば、サービスはデプロイしやすく、本番環境で動き続けるようになる。そして、本番環境では、問題を早い段階で見つけ、解決できるようになり、コンポーネントが故障したときには穏やかにグレードダウンできるようになる。そのような非機能要件の例を挙げておこう。
The DevOps ハンドブック 理論・原則・実践のすべて （20.5 非機能要件を体系化して運用にやさしい設計を実現する、より）

The Top Ten DevOps “Operational Requirements”

というわけで元記事を元にメモ。

  1. Documentation
    • ちゃんとドキュメントを書いてくれ。
      • 俯瞰的な概念図
      • 全ての依存関係
      • 全てのエラーメッセージと詳細
      • すべての設定オプション/スイッチ/フラグ/キーなどの詳細
      • （実行状況）計測機能のエンドポイントと期待値
      • 前提条件、デフォルト値など
  2. Robust Regression Test suite
  3. Automation and “scriptability”
    • 自動化とスクリプト化容易性。未サポートでも将来リリースプロセス等をスクリプト化できるようにしておくこと。
  4. Horizontal Scalability (for all tiers)
    • 全階層における水平方向のスケーラビリティ。
  5. “Feature Flags”
    • フィーチャフラッグ(追加機能をフラグで制御できるようにする)
    • コードベースをロールバックせず、ダウングレードを可能とすること。
  6. Configurability
    • 設定容易性。ハードコードなどもってのほかで、正しく設定できるように構築する。
  7. Backward/Forward Compatibility
    • 後方/前方互換性。これはオンライン中でのアップグレードを行う前提となるため。
  8. Code defensively & degrade gracefully
    • 主にサードパーティサービスに対する防御的な実装と、縮退稼動のサポート。
  9. Keep track of the Dependencies!
    • アプリケーションの依存関係が把握され文書化されていること。
  10. Instrumentation
    • (稼動状況の)計測のサポート。アプリケーションの稼働状況がモニタリングできる方法のサポート。

うん、わかるわかる。

技術書「The Art of Monitoring」ナナメ読み

book safaribooksonline

The DevOps Handbookで紹介されていた「The Art of Monitoring」が面白そうだったのでナナメ読みしたメモ。

The Art of Monitoring (English Edition)

The Art of Monitoring (English Edition)

Web-Scale企業（たとえば、Google、Amazon、Facebook）の運用エンジニアたちが開発し、使っている新しいモニタリングアーキテクチャについては、James Turnbullが著書The Art of Monitoringのなかで説明している。
The DevOps ハンドブック 理論・原則・実践のすべて （14.1 一元的な遠隔測定インフラストラクチャの作り方、より）

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

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

「The Art of Monitoring」読んだ感想。

当初期待していたのはアプリケーションのモニタリングについての抽象度の高い方法論だったのだけれども 、本書はむしろRiemannを中心とした具体的なHowToである。よってこれから構築するシステム、もしくは構築済だがモニタリング機能は手付かずのシステムで、本書で紹介されているプロダクトセット(Riemann,ELK,collectd etc)を用いた監視基盤を構築するのであれば有用だろう。
一方で抽象的な方法論について読みたければ、The DevOps Handbookに本書をベースとした考え方は十分紹介されているのであえて本書を読む必要はないと思う。The DevOps ハンドブック 理論・原則・実践のすべてを読めば十分な印象がある。

なお本書はSafaribooksonlineに登録されているので、下記の方法を取れば購入しなくても読むことができる（できた）。

「The Art of Monitoring」の目次と各章ナナメ読み読書メモ

  • 1 Introduction
    • 興味深い。モニタリングの昨今のトレンドや類別などについて。
    • 「Manual, user-initiated, or no monitoring」＞「Reactive（Monitoring）」＞「Proactive（Monitoring）」という流れ。
  • 2 A Monitoring and Measurement Framework
    • モニタリングフレームワークについての抽象度の高い話で、こちらもいろいろ参考になる印象。
  • 3 Managing events and metrics with Riemann
    • Riemannの導入方法など。
  • 4 Introducing Graphite and Grafana
    • GraphiteとGrafanaの導入方法について。
  • 5 Host monitoring
    • サーバのデータ収集をcollectdとRiemannで実施し、Graphiteに送信するところまで。
  • 6 Using collectd events in Riemann
    • 5章の収集データを用いた監視の実装と、Grafanaによるモニタリング。
  • 7 Containers: another kind of host
    • Docker固有のコンテナ監視について。Dockerから取れるメトリック＋Docker collectdの構成。
  • 8 Logs and logging
    • ログ監視(syslog)を行う。
    • Elasticsearch - Logstash - Kibanaの構成。
    • Rsyslogを使ってsyslog取得。
    • LogstashからRiemann、Graphiteへのメトリクスとイベントの送信。
  • 9 Building Monitored Applications
    • アプリケーションの監視を行うのに、ログだけじゃなくてモニタリングエンドポイントを追加する方法について。
    • アプリにエンドポイントを追加してStatsDで情報収集。
  • 10 Notifications
    • 通知処理のレベルアップについて。コンテキストの追加、メンテナンスとダウンタイムの考慮、クリティカルではない参考情報の追加。
    • GrafanaのScripted Dashboardの活用。
    • Slack/PagerDutyへの出力。
    • Riemannでのメンテナンスイベントのハンドリング。
  • 11 Monitoring Tornado: a capstone
    • 応用編。アプリケーションスタック全体を管理、測定、通知する方法について。
    • Part1として、仮想アプリケーション「Tornado」のWeb層のモニタリングを設定する。
    • HttroxyやNginxの情報を取り扱う方法。
  • 12 Monitoring Tornado: Application Tier
    • 応用編の続き。仮想アプリケーション「Tornado」のAP層のモニタリングを設定する。
    • JVM監視、ログ収集、アプリ自体のヘルスチェック(APIに仕込む)など。
  • 13 Monitoring Tornado: Data tier
    • 応用編の続き。仮想アプリケーション「Tornado」のDB層のモニタリングを設定する。そして統合ダッシュボードを組む。
    • collectdでmysqlとredisからデータを収集する。
    • Grafanaで「Tornado」ダッシュボードを構築する。
  • 14 An Introduction to Clojure and Functional Programming
    • Riemannのカスタマイズに用いるClojureの説明。

英語技術書を機械翻訳で読みまくる方法

safaribooksonline Professional Engineer book

ふとしたキッカケで英語技術書を機械翻訳で読みまくれる環境を整備したら非常に快適になったのでご紹介。要約すると、定額制無制限の書籍サイトに加入して、バルクでGoogle翻訳をかけてざっくりと技術書を読む方法について。

https://www.flickr.com/photos/62277986@N00/2904221707

これまでの英語技術書読書環境の問題点

というわけで原著（洋書）をコピペラブルな状態で購入できないの？
と考えていろいろ調べたところ、予想外に有用な方法が判明したのだった。

SafariBooksOnlineが予想以上に優秀

さて、いろいろと調べてみると現在米オライリーは単品での電子書籍の直販は行っておらず、定額読み放題のサービスをメインとしているようだ。

なるほど。というわけでさっそく SafariBooksOnlineを調べてみると、有料ながら

というわけで超優秀なのである。

費用の問題

ところがSafariBooksOnlineはコンテンツが充実している一方で、お値段は相応である。月額39$、年額399$とちょっとお高い。

が、いろいろ調べてみると様々な学会などの会員サービスとして利用するという裏技があるのである。例えばACMの会員になれば年額99$で無制限にアクセスできる。これは安い！（なお、過去には利用方法に制限があったようだが、現在はフルサービスが利用可能のようだ）

追記：会員特典としてO'Reilly Online Learningが利用できるオプションは2022/7/1からは利用できなくなります

まとめ：英語技術書を機械翻訳で読みまくる

というわけでまとめると

  • ACM会員登録して得点のSafariBooksOnlineアクセス権をゲット
  • Chromeでアクセスして機械翻訳

で、読みまくる環境を実現することができる。これで、PCからでもモバイルからでも好きなだけ最新の技術書を読むことが可能である。
興味を持ったらまずSafariBooksOnlineで無料トライアルを試したあと、そのアカウントは捨ててACM会員登録するのがオススメである。

で、最近何を読んでるかというと

The Site Reliability Workbook: Practical Ways to Implement SRE

The Site Reliability Workbook: Practical Ways to Implement SRE

  • O'Reilly Media
Amazon
いったん読み終わって

現在はこちらの本を読んでいる

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

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

Amazon

いやあ、良い世の中になったものだ。

参考

Postmortem Culture: Learning from Failure（Site Reliability Engineering Workbookつまみ食い#2）

Professional Engineer Postmortem book

引き続き、「The Site Reliability Workbook: Practical Ways to Implement SRE」をつまみ食い中。今回は同書の「Chapter 10. Postmortem Culture: Learning from Failure」に関して。ポストモーテムなんて言葉は数年前までまったく聞いたことがなかったのだけれども、自分のまわりでは最近急速に定着しているような気がする。ちなみにポストモーテムとは、障害の事後分析のことである。あるいは検死解剖。

The Site Reliability Workbook: Practical Ways to Implement SRE

The Site Reliability Workbook: Practical Ways to Implement SRE

  • 作者: Betsy Beyer,Niall Richard Murphy,David K. Rensin,Kent Kawahara,Stephen Thorne
  • 出版社/メーカー: O'Reilly Media
  • 発売日: 2018/08/04
  • メディア: ペーパーバック
  • この商品を含むブログを見る

ポストモーテムについて

原典はおそらく以下の記事だと思われる

ポストモーテムは、インシデントとそのインパクト、その緩和や解消のために行われたアクション、根本原因（群）、インシデントの再発を避けるためのフォローアップのアクションを記録するために書かれるものです。
SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム 15 章 ポストモーテムの文化：失敗からの学び

他には以下の記事がわかりやすい（原文は英語だけど、postdで翻訳されている）。

「The DevOps ハンドブック 理論・原則・実践のすべて」ではポストモーテムは、「非難なしのインシデント後レビュー（blameless post-incident review）」とか「事象発生後のレトロスペクティブ（post-event retrospective）」などとも呼ばれているものである。

蛇足だけど、上記ブログポストの筆者danluuさんがネットで読めるポストモーテム集をgithubに公開しているようだ。

Postmortem Culture: Learning from Failure

「SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム」ではポストモーテム概論（15章）とポストモーテムの実例1つ（付録D）の記載があるが、「The Site Reliability Workbook: Practical Ways to Implement SRE」では具体的なケーススタディ（悪いポストモーテム、良いポストモーテム例）、具体的に良いポストモーテムを書くためのテンプレートやチェックリストに言及されていてより実践的なものとなっている。

以下、「The Site Reliability Workbook: Practical Ways to Implement SRE」で新たに紹介されている各種リソースが有用そうだったので備忘的にピックアップ。