勘と経験と読経

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

ACM Professional Membershipの登録

思うところがあって、ACM Professional Membershipに登録したメモ。ACMチューリング賞などで有名な米国の計算機学会。会員になると学会誌Communications of ACM (CACM)が読めたり、論文や様々な情報にアクセスしたり、特典としてSafari Books Online でO’Reillyの書籍(英語)が読み本題になったりする。年会費は99$。

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

登録方法メモ

  • Association for Computing Machineryから、Join > Online Forms > Professionals
  • 必須項目を中心に入力
    • First Name, Last Name
    • Address関連 (Postal Codeはハイフンを抜いて記入)
    • Contact Information関連(電話番号は+81で登録)
    • Professional Member Profile(年齢、性別、主要な職業、職位Job Title、所属Affiliation)
    • Membership Optionは単純な「Professional Membership」で良い(ACM Digital Libraryはいらないと思う)
  • Continueすると、いろいろオプションを追加できる見積もり画面になるが、特にオプションは追加しないで決済に進む
  • 自分はPaypalを使ったけれど、カード決済もできそう
  • 決済が終わったら登録完了
  • その後、Create Web Accountに進む
    • 先ほど登録したメールアドレスを入力すると、アカウント作成画面になる
    • パスワード等を登録。アカウント名は自動生成されるようだ(もしかしたら好きなIDに変更出来たかも)
    • 登録が終わったら、自分のメールアドレスにConfirmメールが届くので、リンククリックで完了
  • これで完了、アカウント名@acm.orgの転送専用メールアドレスが作成される

Safari Books Onlineの利用

PagerDuty Incident Response Documentationが良さそう(Site Reliability Engineering Workbookつまみ食い#1)

前回の記事で紹介した「The Site Reliability Workbook: Practical Ways to Implement SRE」が気になるので、興味があるところから適当に読んでいる。

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/07/25
  • メディア: ペーパーバック
  • この商品を含むブログを見る

今回は同書の「Chapter 9 Incident Response(インシデント管理)」を読んだのだけれども、その中で紹介されているPagerDuty Incident Response Documentationがかなり有用そうな印象。

前作「SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム」にも同様の章があったのだけれども、続編となる本書では具体的なケーススタディ(良いものと悪いもの)を中心にまとめられている。ケースは基本的にGoogleの障害だが、4例のうち1例だけ、表題のPagerDutyの事例になっている。加えて同社はなんと、インシデント対応に関する社内教育文書をネットに公開しているというのだ。

というわけでざっと(Chromeの翻訳機能を使いながら)読んだ見たのだけれどもかなり興味深い。ドキュメントのソースもgithubで公開されているので流用することもできそうだ。

蛇足

無料公開されたSite Reliability Engineering Workbookが面白そうなので目次を機械翻訳

SREを実践するための手引きとなる書籍「Site Reliability Engineering Workbook」をGoogleが無料公開、8月23日まで - Publickeyで知ったのだけれども、以前に読んで大変参考になった「SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム」の続編「The Site Reliability Workbook: Practical Ways to Implement SRE」が無料公開中だ。もちろん続編は英語のみ。

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

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

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/07/25
  • メディア: ペーパーバック
  • この商品を含むブログを見る

無料なのは大変ありがたいのだけど前作同様に大著でハジから読むのはちょっと骨が折れそう。せめて目次だけでも日本語で読みたいと思ったので少し調べてみたら、Safari Books Onlineで目次は全部公開されていたのでGoogle翻訳にかけてみた。十分読める翻訳になっているようだ。
というわけで、気になる章から読んでみようかと思っている。

日本語で読めるperf linux profilerの情報を整理する

最近いろいろとperf linux profilerについて調べていたので、見つけた日本語情報を中心にまとめておく。あまり需要はなさそうだけど。

Speed

書籍で読めるperfの情報

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

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

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

パフォーマンスの大家Brendan Greggが書いた本であり、詳しく紹介されている。しかし、それでも主要なコマンドの実行例が中心であり、取り上げられていない機能も多い。最初のとっかかりとして読むのが良さそう。具体的には次のような章立てで紹介されている(約8ページ)。

  • 6章 CPU
    • 6.6.12 perf
      • システムプロファイリング
      • プロセスのプロファイリング
      • スケジューラのレイテンシ
      • stat
      • ソフトウェアトレーシング
      • ドキュメント

perf(1) コマンドは、もともと PCL(Performance Counter for Linux)と呼ばれていたが、その後プロファイリングとトレーシングのためのツールコレクションに発展し、現在は LPE(Linux Performace Events)と呼ばれている。各ツールは、サブコマンドとして選択される。たとえ ば、perf statは、CPCベースの統計を提供するstatコマンドを実行する。
詳解 システム・パフォーマンス

LINUX カーネル HACKS

Linuxカーネル Hacks ―パフォーマンス改善、開発効率向上、省電力化のためのテクニック

Linuxカーネル Hacks ―パフォーマンス改善、開発効率向上、省電力化のためのテクニック

詳解 システム・パフォーマンス」より大分詳しく紹介されている(約24ページ)。特に、perf scriptとperf probe について詳しく書かれているのが有り難い。また、ftraceなど他のツールも紹介されていて勉強になる。章立てはこんな感じ。

  • 8章 プロファイリング、トレース

ソフトウェアやシステムのスループットやレイテンシを改善することで、計算機を効率よく使うことができます。特にOSSでは、自分でソースコードを手に入れ、これらのパフォーマンスを改善することが可能です。
Linuxカーネルの開発者たちも、品質を向上するためにパフォーマンス解析を行っています。このため、カーネル内に様々なパフォーマンス解析や動作解析を行うための機能が追加されています。この章では、perf toolsによるパフォーマンス解析や、ftraceを使った動作解析、SystemTapを使ったプログラマブルトレーシングなどを説明します。もちろん、これらの機能は、カーネルのパフォーマンス解析だけでなく、ユーザプログラムの解析や、システムのトラブルシューティングなどにも有用です。
Linuxカーネル Hacks ―パフォーマンス改善、開発効率向上、省電力化のためのテクニック

2018年上半期に読んだ本まとめ

2018年1月~6月に読んだ本のまとめ。カウント対象は期間中に読み終わったものに限り、読みかけの本は対象外としている。あと雑誌コミック類もけっこう読んでいるのだけれども、これは除外。

2018年上半期に読んだ本

2018年1月~6月に最後まで読み終わった本はこんな感じ。

  1. 進化する銀行システム 24時間365日動かすメインフレームの設計思想
  2. 騎士団長殺し :第1部 顕れるイデア編
  3. モチベーション革命 稼ぐために働きたくない世代の解体書 (NewsPicks Book)
  4. [asin:B01MYNIDO2:title]
  5. カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで
  6. アロウズ・オブ・タイム (新☆ハヤカワ・SF・シリーズ)
  7. GE 巨人の復活
  8. あなたの人生の物語
  9. 香匣は心臓を望む (Amazonから消えてしまった)
  10. 「組織が結果を出す」非常識でシンプルなしくみ
  11. まなざしのデザイン
  12. 影響力の正体 説得のカラクリを心理学があばく
  13. テスタメントシュピーゲル3 下 (角川スニーカー文庫)
  14. [asin:B0719WDHQ7:title]
  15. パケットキャプチャの教科書
  16. ZERO BUGS シリコンバレープログラマの教え
  17. 公正的戦闘規範 (ハヤカワ文庫JA)
  18. 1440分の使い方 ──成功者たちの時間管理15の秘訣
  19. 習得への情熱 チェスから武術へ――上達するための、僕の意識的学習法
  20. 飛行士たちの話
  21. 悪童日記
  22. 詳解 システム・パフォーマンス
  23. [asin:B077LWT7WB:title]
  24. 9プリンシプルズ 加速する未来で勝ち残るために (早川書房)
  25. [asin:B076HMM5CQ:title]
  26. NATURE FIX 自然が最高の脳をつくる 最新科学でわかった創造性と幸福感の高め方
  27. 不確定世界の探偵物語 (創元SF文庫)
  28. 棋士とAI-アルファ碁から始まった未来 (岩波新書)
  29. セキュリティコンテストチャレンジブック CTFで学ぼう!情報を守るための戦い方
  30. 決定版 上司の心得 (角川新書)
  31. 退屈をぶっとばせ! ―自分の世界を広げるために本気で遊ぶ (Make: Japan Books)
  32. [asin:B079P3Q4N3:title]
  33. [asin:B079P1R3T4:title]
  34. チームが機能するとはどういうことか ― 「学習力」と「実行力」を高める実践アプローチ
  35. [asin:B00SF6JN7M:title]
  36. 多動日記(一)「健康と平和」: -欧州編- (電子版 未来文庫)
  37. 世界一やさしい「思考法」の本 「考える2人」の物語
  38. アメリカ海軍に学ぶ「最強のチーム」のつくり方―――一人ひとりの能力を100%高めるマネジメント術
  39. 世紀の空売り 世界経済の破綻に賭けた男たち (文春文庫)

オススメビジネス書編

このシーズンは能力開発/自己啓発の名著の類の積読を頑張って消化してたのだけど、あまりアタリは無かったかなぁ。そんな中で、「世界一やさしい「思考法」の本 「考える2人」の物語」は有用度が高かった。自分というより後進指導の悩み比率が高まるお年頃なわけで、平易に伝える方法が書かれているのも良いし、人によっては丸投げても読んでくれそうなハードルの低さ。

業界分析/研究カテゴリーで言えば「GE 巨人の復活」は評判通りの良書で、いろいろと刺激があった。この類の本は訳書が多いのだけど、本書は最初から日本語で書かれた邦書である。おそらく製造業の方向けに書かれた本なので、ソフトウェア開発技術者であれば、そんなに新しい話があるわけではない。が、巨人がエクストリームな方向転換をしたこと、及びそのアプローチは非常に興味深い。

GE 巨人の復活

GE 巨人の復活

オススメ技術書編

元からソフトウェアの低レイヤ技術(OSとかコンパイラとかネットワークとか)には興味と憧れがあったのだけれども、ちょうど仕事でも近しい領域の課題があったので集中的な勉強を始めたところだったりする。というわけで、話題の技術書の類はぜんぜん手に取っていない点は反省。一方で学び始めた領域はとても面白く、今はOSの作り方などを勉強し始めてたりする。

繰り返し読んだ本は「詳解 システム・パフォーマンス」で、システム屋としてはこの本でいろいろととっかかりを手に入れた気がする。副読本(教科書)として、以前にセールで手に入れていた所謂[asin:B00SF6JN7M:title=ヘネパタ本]を読んで、いろいろと知識が深まった気がする。

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

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

  • 作者:Brendan Gregg
  • 発売日: 2017/02/22
  • メディア: 単行本(ソフトカバー)
[asin:B00SF6JN7M:detail]

あと、せっかくなので得た知識を楽しむという点で「セキュリティコンテストチャレンジブック CTFで学ぼう!情報を守るための戦い方」でいろいろと刺激を得ることができた。セキュリティというテーマの競技に関するガイドなのだが、本書を読んだあと、公開されてる様々な問題を解く(プログラムを解析したり脆弱性を利用して、隠されている答えを手に入れるゲームである)にチャレンジし始めている。新しい学びがあり、なかなかに楽しい。

この半期の振り返り

年齢と職責的には、もっとマネジメントやら人心掌握術、戦国武将の話とかを読むべきような気もするのだけれども、むしろ逆に振り切ってしまったような気がする。せめて積読している「ティール組織 ― マネジメントの常識を覆す次世代型組織の出現」は読み終えたかったのだけど食指が動かないのはなぜなんだろう。

あと気になるのは視力の問題である。幸運にも目は良くてメガネもコンタクトも不要なのだけれども、疲れたり酒を飲むと、読書がつらいことがある。もしかして老・・・。

まあ、電子書籍は必要に応じて文字サイズが変えられるのでかなり助かっているのだが。

産業安全についての神話(Some myths about industrial safety)について調べた

The DevOps ハンドブック 理論・原則・実践のすべてで紹介されていた「産業安全についての神話」(補章E)が面白そうだったので調べてみた。ソフトウェア開発に限らず、工学全般の話。

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

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

複雑なシステムに対する数十年の研究の結果、危険への対応策はいくつかの神話に基づいていたことがわかった。

原文はおそらくこれ

なお以下私の誤読の可能性もあるので、興味があれば上記の原典論文を参照のこと。

神話1:事故やインシデントの唯一最大の原因はヒューマンエラーである

原因をヒューマンエラーと分析すること自体に誤りがある。

  • 不正行為の暗示
  • 犯人探し
  • 後付けバイアス

であり、作業環境の不備や不足の隠蔽に繋がる。よって、問題の原因をヒューマンエラーと説明すべきではない。
また、問題の行動がが通常どのような状況下で行われるのかについて検討をすべきである。

神話2:システムは、人々が与えられた手順に従っていれば安全である

全ての事象をカバーする完全な手順を構築することが不可能であること、および本来人間が持っている柔軟性を制限することが有害である場合があることから誤りである。

神話3:安全性は障壁と保護によって上がる。保護の階層を増やせば、安全性は上がる

一見すると正しく見えるが、追加的な保護が人々の行動を変化させ、結果として安全を損なう場合を考慮する必要がある。曲がりりくねった道路に夜間安全対策として反射板を追加したところ、車の走行速度が増して、事故率が増加したという話などが紹介されている。
また、保護機構の追加によってシステムそのものの複雑度が増し、それによって安全性が低下する懸念もある。

神話4:事故分析は、事故が起きた根本原因(「真実」)を明らかにすることができる

根本原因分析は簡単な手法であり魅力的だが、必ずしも原因究明できるとは限らない。特に人間が関わるシステムの問題においては、人の持つ柔軟性、弾力性を考慮すると誤った分析や、前述の「ヒューマンエラー」を根本原因としてしまう可能性がある。

神話5:事故調査は、事実に基づいて原因を論理的、合理的に究明する

手法の選択を含めて事故調査は難しいプロセスであり、かつバイアスから逃れることは出来ないため、必ずしも論理的、合理的な結論に至るわけではない。またプロセスによって原因を発見するのではなく構築してしまいがちである。

神話6:安全には常に最高の優先順位が与えられており、決して妥協はない

言うまでもなく、組織がその負担をする余裕がある限りにおいては、という話である。

「5億ドル?!を吹っ飛ばした、たった1つのバグ!」について調べた

久しぶりのブログ更新。書籍「ZERO BUGS シリコンバレープログラマの教え」を読み終えた。この本の中で紹介されている歴史的なソフトウェア障害が気になったのでいろいろ自分で調べてみたメモ。トラブル好きなもので。


アリアン5型ロケット爆発事故(1996年、European Space Agency)

失敗事例 > アリアン5型ロケットが制御不能で40秒後に爆発
失敗百選-アリアン5型ロケット爆発事故
アリアン5 - Wikipedia
https://wired.jp/2005/11/16/%E3%80%8C%E5%8F%B2%E4%B8%8A%E6%9C%80%E6%82%AA%E3%81%AE%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%83%90%E3%82%B0%E3%80%8D%E3%83%AF%E3%83%BC%E3%82%B9%E3%83%8810%E3%82%92%E7%B4%B9%E4%BB-2/

ZERO BUGS日本語版の表紙のアオリ文句「5億ドル?!を吹っ飛ばした、たった1つのバグ!」のトラブル事例である。被害額は訳者の調べであり原著者は文中で言及しているわけではない。5億ドルは吹っ飛んだロケット+ペイロードの総額であり、開発費用はっと大きかったという話もあるようだ。なお書籍には実際のコードも掲載されていて興味深い。

もちろんコードに問題があったことは確かなのだけど、調べてみるとこのトラブルはプロジェクトマネジメントと品質管理の問題のように見える。トラブルのアウトラインは以下の通り。

  • 飛行コンピューターでオーバーフローが発生し、最終的にロケットが発射直後に爆発した。
  • この飛行コンピューターのコードを一世代前のロケットから引き継いでおり、新規に開発したものではない。
  • 新型ロケットでは加速度が旧型より増加しており、結果として計算処理でオーバーフローとなった。要は前提が変わっていることが見過ごされた。
  • 飛行コンピューターは稼働実績ありという理由で詳細なテストは行われなかった。

合掌(チーン)。

ちなみにWikipediaの記事ではこの失敗が

1996年6月4日に行われたアリアン5の最初の飛行は、コンピュータプログラムの異常で打ち上げ37秒後に爆発し、失敗に終わった。これは歴史上でも最も高くついたバグの1つであり、後に64ビットの浮動小数点数を16ビットの整数に変換する過程でエラーが生じたと判明した。

と書かれているのだけど、この記載(下線部)はあやしい。英語版記事を元に書かれたものだと思うけど、
Cluster (spacecraft) - Wikipedia

The failure has become known as one of the most infamous and expensive software bugs in history.[1] The failure resulted in a loss of more than US$370 million.[2]

英語版記事の情報源[1]がそもそも1996年のエッセイなのである。

被害額も記事によってまちまちなので注意したほうがよさそう。