2/17/2017

Googleでのソフトウェア・エンジニアリング (2.9、2.10、2.11)

Googleでのソフトウェア・エンジニアリング」と題する論文。

2.9. ローンチの承認

ユーザから見える変更、あるいは重要な設計変更のローンチには、変更を実装するコアエンジニア・チームの外の多くの人からの承認が必要である。特に、承認(しばしば詳細なレビューの対象となる)はコードが法的要件、プライバシー要件、信頼性要件(例えば、サーバの障害を検知する適切な自動監視を行い、適切なエンジニアに自動的に通知する)、ビジネス要件などに従うことを保証する必要がある。

ローンチ・プロセスは、重要な新製品や新機能が登場するたびに、社内の適切な人物に通知されるように設計されている。

Googleは、必要なレビュー、承認、各製品ごとに定義されたローンチ・プロセスが遵守されているかを追跡するのに使われる内部ローンチ承認ツールを持っている。このツールは簡単にカスタマイズでき、様々な製品あるいは製品分野で必要な様々なレビューや承認に対応できる。

ローンチ・プロセスの更なる情報は、SRE本の第27章を参照いただきたい[7]。

2.10. 事後分析 (Post-mortems)

我々のプロダクション・システムに重要な障害、あるいはそれに類する事故が発生した場合、関係者は事後分析のドキュメントを書く必要がある。このドキュメントは、タイトル、概要、影響、経過、根本的な原因、作業したもの/作業をしなかったもの、アクション・アイテムなどを含むインシデントを説明する。焦点は問題への取り組みにあり、今後回避する方法、人に責任を向けるのではなく分かち合うことにある。インパクト・セクションでは、障害の継続時間、失われたクエリの数(あるいは失敗したRPCなど)、および収益の観点から、インシデントの影響を定量化しようとする。タイムライン・セクションでは、障害につながるイベントのタイムラインと診断と、それを是正する手順を示す。何を実施して、何を実施しなかったのかの区分が、どの仕事が問題を迅速に検知して解決の手助けになったのか、何がうまくいかなかったのか、どの具体的な活動が(おそらく、特定の人に割り当てられるバグとして届けられた)将来の同様の問題の可能性や重度を減らすことができるかを学習する知識を類型化する。

2.11. 高頻度の書き直し (Frequent rewrites)

Googleのほとんどのソフトウェアは数年ごとに書き直される。これは信じられないほどコストが掛かると思われるかも知れない。確かに、Googleのリソースの大部分を使っている。しかし、Googleの敏捷性や長期的成功にとって鍵となる極めて重要な利点もある。数年で、製品要件は著しく変化し、周辺のソフトウェア環境や他のテクノロジも変化し、テクノロジあるいは市場の変化がユーザのニーズ、欲求、期待に影響を与える。数年前のソフトウェアは、より古い要件で設計されており、現行の要件に最適な方法で設計されていない。さらに多くの複雑さが積み重なっている。コードを書き直すことは、もはやそれほど重要ではない要件に対処していた不要で積み重なった複雑さを全て除去できる。加えて、コードの書き直しは、知識や当事者意識を新しいチームのメンバーに伝える方法でもある。この当事者意識は生産性にとって非常に重要である: エンジニアは機能を開発したり、コードの問題を自分のこととして感じて修正することに自然と努力を注いでいる。高頻度の書き直しは、様々なプロジェクト間のエンジニアの流動性を促し、アイデアの相互交流を促すのにも役立つ。高頻度な書き直しは、コードが最新のテクノロジーと技法を使って描き直されることにも確実に役立つ。