Release It! 本番用ソフトウェア製品の設計とデプロイのためにを読んだ
存在は知っていたけど読んだことがなかったので読んだ。日本語版が2009年、原著が2007年とちょっと古いのだけど、本質的な所は変わらないのでは？と考えたのがきっかけ。
p12 優先すべきはサービスの回復。原因調査はその次。
当たり前なのだけど、僕はついつい原因が何だろうと追いかけてしまいがちだ。改めて、サービスはユーザが利用できてこそだなあと強く認識。
p16 大きな事件の後では関係者の心証の管理が障害そのものの管理と同じくらい重要
情報を公開する姿勢や実際にすることが大事、という感じ。
p24 一過性のインパルス（衝撃）や持続的なストレス（圧力）、あるいは通常の処理が阻害される構成要素の障害があってもトランザクションを処理し続けるのが弾性（回復力）のあるシステムだ
この本が書かれた時代と2017年では状況がかなり違うだろうし、ソフトウェアの質によってもとるアプローチは異なるだろうけど考え方としては全く同じだなあ。
p107 fiddingを助長しないこと。システムは介入なしでいつまでも動き続けるべきである
状況が変化する以上全く介入しないというのは無理だけど、極力手でシステムを触ることを減らすべき、という観点では同意。
※ finding = もてあそぶこと。いじくりまわすこと。
p249 リカバリ指向コンピューティング
被害を一部に抑えること、障害の自動検出、コンポーネントレベルでの再起動など、今当然のようにやっていたり、やりたいねという概念だった。
p289 O-O-D-A
「Observe（観測）、Orient（判断）、Decide（決心）、Act（行動）」とのこと。フィードバック・ループを含んでいるところが結構自分の関心領域に近いなあと感じた。関連文献読んでみたいところ。
p316 リリースがソフトウェアの生涯の真の始まりであり、それ以前は全て妊娠期間だ。システムは時とともに成長し、変化する環境に適応していくか、あるいはコストが収益を上回るまで墜落して死に至る。
よいなあと思った。もちろん、無事誕生日を迎えるまでも滅茶苦茶大変なわけだけど、生まれてから面倒を見るのだって同じくらい大変なわけだ。どちらが偉いとかじゃなくて、役割の違いということかな。
Release It! 本番用ソフトウェア製品の設計とデプロイのために
posted with amazlet at 17.09.04
Michael T. Nygard
オーム社
売り上げランキング: 214,686