Microsoft の DevOps 実践の第一人者の Sam Guckenheimer が長年の経験をもとに、DevOps をうまく実践するための７つの習慣をまとめてくれました。その内容を原文と共に共有したいと思います。

f:id:simplearchitect:20160513160644j:plain

７つの習慣は特に DevOps のマインドセットを学びたい人にはとてもいいまとめになっています。「リードタイムの短縮」以上の Advanced DevOps を学びたい人にもお勧めです！簡単に翻訳してみましたが翻訳や、解釈の間違いがありましたら是非コメントをお願いいたします。

1. Production First Mindset （本番を第一に考える)

Production is the heart of any software delivery organization, and the best ones recognize that the real production should be top priority for every team member in every role, not just IT operations. Intermediate artifacts like documents and disconnected pre-prod environments are not enough. High performers always track the live site status, remediate any live site issues at root cause, and proactively identify any outliers in performance to see why they are experiencing slowdowns.

本何環境は、ソフトウェアを作成する組織の心臓部です。すべての役割の人(Dev, Ops, PO, Manager...)にとって、最もプライオリティが高いものであるべきです。ITPro (インフラ/運用技術者)にとってだけ優先順位が高いわけではありません。ドキュメントや、プロダクション以前の環境の成果物では十分ではありません。ハイパフォーマーは常にライブステータスをトラッキングし、根本原因の特定や、問題が発生する前にパフォーマンスが悪化している人がなぜそんな目にあっているのかを理解することで、ライブサイトの問題を軽減するようにしていいます。

2. Backlog Groomed with Learning (学びから Backlog をブラッシュアップする)

The Backlog is the stack of work to be done. Different organizations plan, define and manage requirements and projects differently. This can include how you engage with stakeholders and how you request, capture, and track work. It can also include how well you align, agree, and make decisions. High performers treat the backlog as a set of hypotheses, which we need to turn into experiments, and for which they need to collect data that supports or diminishes the hypotheses. Based on that evidence they can determine the next move in the backlog and persevere (do more) or pivot (do something different).

バックログは、すべき仕事が積まれたものです。組織の計画と異なり、要求とプロジェクトでの違いについて定義して管理します。このことは、どのようにあなたが、リクエストしたか、とらえたか、そして、トラッキングしたか、さらに利害関係者を巻き込むかも含まれています。また、あなたが、どのように整合性をとって合意して、意思決定するかも含まれます。ハイパフォーマーは、バックログを、「仮説」の集合としてとらえます。ですので、我々は、仮説を検証するために、「実験」して、「仮説」を検証する、もしくは、それが外れていることを証明するデータを集める必要があります。エビデンスに基づいて、バックログのなかで、次にどうするか、そのままの考えですすめるのか、それともピボット（何か違うことをすること）するのかを決定していきます。

3. Evidence Gathered in Production (エビデンスを本番で集める)

Good decisions are informed by data. High performers instrument everything, not just for health, availability, performance, and other qualities of service, but to understand usage and to collect evidence relative to the backlog hypotheses. For example, they will experiment with changes to user experience and measure the impact on conversion rates in the funnel. They will contrast usage data among cohorts, such as weekday and weekend users, to hypothesize ways of improving the experience for each.

良い意思決定は、データによってもたらされます。ハイパフォーマーはすべてを収集します。ヘルスチェックや、可用性、パフォーマンスそして、他のサービスの品質属性だけではありません。ユーザの利用状況や、バックログの仮説検証を支えるためのデータをも取得します。例えば、あるチームが、ユーザエクスペリエンスの変更を実験していたとしますそして、フューネルのコンバージョン率へのインパクトを測定していたとします。彼らはきっとコホート分析の利用率のデータを比較します。週中、週末の利用率です。ユーザエクスペリエンスを改善するためにの、か改善仮説の検証のためです。

4. Flow of Customer value (顧客価値のフロー)

Flow refers to an organization’s ability to move software swiftly from initial idea through creation and validation into a production release, without impediments or rework loops. Reduced rework allows teams to focus on delivering more net-new value. Shorter cycle times support increased responsiveness, in turn fostering stakeholder satisfaction and trust.

フローは、ある組織が、ソフトウェアを、最初にアイデアを思いついてから、ものづくりをして、検証して、本番にリリースするのをいかに早くできるかの能力です。もちろん、障害や作業のやり直しをすることなくです。再作業を少なくすることで、チームは新しい資産価値を生み出すことに集中することができます。短いサイクルタイムは、市場への反応性をあげます、それにより、株主の満足と信用を得ることができます。

5. Team Autonomy and Enterprise Alignment (チームの自立性とエンタープライズへの適合)

The goal for modern application delivery is responsiveness, which relies on flexible scheduling, limiting long-term commitments in favor of iterative experiments, and close team collaboration to facilitate real-time communication and eliminate wasteful handoffs. High performers have multidisciplinary feature crews who pull from a common product-backlog, minimize work in process, and deliver work ready to deploy live at the end of each sprint.

モダンなアプリケーションデリバリのゴールは、「反応性」です。それは次の要素に依存しています。柔軟なスケジュール、繰り返し型開発により長い期間のコミットメントを制限すること、密接なチームのコラボレーション、リアルタイムなコミュニケーションそして、無駄な「ハンズオフ（成果物を他の人に引き渡すこと）」を削減することです。ハイパフォーマーは、様々なスキルをもった人があつまった、(権限をもち自立した)バックログを実行するフィーチャーチームのメンバが、仕掛仕事を最小化し、毎スプリントの終わりに、本番にデプロイできる成果を作り出します。

6. Managing Technical Debt (技術的負債を管理する）

The Technical Debt category considers behaviors for strategically managing the impact of short-term and long-term technical decisions.

技術的負債は、短期、長期のインパクトを鑑みて、戦略的に技術的決定を実施していくことを管理するふるまいのことです。

7. Managin infrastructure as a Flexible Resource (インフラを柔軟なリソースとして管理する)

The best performers use the flexible infrastructure of the public cloud and continually improve their architecture to refactor into more independent, discrete services. Using the cloud provides scale on demand and makes it easy to stand up services for continuous feedback from constant usage.

最高のパフォーマンスを出すチームは、パブリッククラウドの柔軟なインフラを使って、継続的にアーキテクチャを改善し、より独立性が高く、分離されたサービスにリファクタリングします。クラウドは、コンスタントな利用状況からの継続的フィードバック基づいて、需要に合わせてスケールするようなことが簡単になります。