Release It!

Release It! 本番用ソフトウェア製品の設計とデプロイのために

Release It! 本番用ソフトウェア製品の設計とデプロイのために

 最近、想定ユーザ数がかなり多いアプリケーションの開発に(末端の開発者として)関わったが、悲しいかな、この本を読んで何も知らなかったという気分にさせられた。そして恐ろしくもなった。
例えばケーススタディにこうある。

数百の旅客機と数万人の社員を擁し、全世界を股にかける数十億ドル規模の巨大航空会社の運行をストップさせたのは、たった1つのSQLExceptionの捕捉を怠るという、一人のプログラマが犯した初歩的なミスだったのだ。 (p.21)

サービスというものが、作り方によっては一行のコードから全体まで、いかに容易に密結合できるか、ということを教えてくれる。また、

依存システムがみんな、あなたのシステムと同じSLA(サービス品質保証契約)を提供するようになっていなければ、どうがんばっても最も低いSLAを提供するサービスプロバイダと同じ程度のSLAしか望めない。 (p.87)

ということで、当然ではあるが接続する他のシステムにも深い理解が必要となる。


 ただし著者が、開発時にすべてのケースを想定、テストし、万全な状態で送り出すべきと書いている訳ではない。現実のテスト環境は、いかに実環境とは違うかということが列挙されている。(ex. p.133)


対処法としてあげられているのは、直接キーワードとしては出てこないが、伝統的な"分割して統治せよ"だろう。

このようなことが、コード、ログ、ハードウェア構成と多層的に言及されている。そして実運用でしか把握しえない問題を一つずつ潰していくことを勧めている。


 印象に残ったものとしては

OODAループ
Observe-Orient-Decide-Act(観測-判断-決心-行動)ループ。(p.289) PDCAサイクルの別バージョンかな。
リカバリ指向コンピューティング
http://roc.cs.berkeley.edu/

よいテストハーネスは狡猾であるべきだ。実世界のシステムと同じだけ厄介で不品行でなければならない。テスト対象のシステムに傷を残すくらいでいい。(p.120)

トランザクションとレポート作成を混ぜるな(p.181)*1

リリースは散髪と同程度のイベントでなければならない(p.309)

などがあった。


 ツールで気になったものとしては、

  • logrotate
  • JVMの -noclassgc オプション、-verbosegc オプション
  • jconsol
  • cfengine

などがあった。




 (経験から)
 この本を読んでいてずっと感じたのは、設計の際にすべての要素を考慮する必要があること。それがアーキテクトだと言えばそれまでだが、現状との間にひどいギャップを感じる。アーキテクトはコードの先の先まで考慮できるだろうか。一部のコンポーネント開発を請け負う開発者は、運用のことまで考えてコードをかけるだろうか。著者はアジャイル開発、特にリファクタリングを推しているが、最初に設計しておくべき内容がかなり大きいようにも見える。果たしてそのバランスはどこで誰がとるのだろうか。
p.312 のダウンタイムがゼロのデプロイ というのは、実際にサービスを運用している会社では当たり前のことなのかもしれないが、いざ並べられてみるとコードからハードまで、実に多層的に考えておかなかければならない。それぞれ請け負う会社が違うような状態で、そんなことが可能だろうか。


 全体としては、開発者からはやや遠く運用者が直面する問題が主体だが、実は開発する際に考慮しなくてはならない内容が満載で、開発者必読だろう。また開発と運用の距離をいかに縮めるかということは、スムーズな開発・保守を考える上で重要なファクターだということを再認識させてくれた。


気になる点としては、想定の規模がつねに大きすぎることか。1時間あたり100万円の売上、なんて言葉が頻繁に出てくる。これはつねに実際の案件規模に置き換えて考える必要があるだろう。そういう、一覧表があるといいかな?

*1:自分のコントロール外のシステムではあったがなんか見覚えが…