QCon New York 2日目 – Developer Experienceトラックのまとめ

QCon New Yorkの2日目、Netflixでエンジニアリング・ディレクターを務めるSangeeta Narayanan氏のホストにより、Developer Experienceトラックが行われた。

彼女はDeveloper Experience (Dev-Ex) のフォーカスを次のように説明する。

開発者体験（Developer Experience）というのは、ソフトウェアの開発、デプロイ、運用、サポートのプロセスをシンプルにすることで、効果を最大化することです。継続的デリバリーのようなプラクティスは、それに向けた大きなステップですが、私たちは他の様々な領域でもうまくやる必要があります。

最初のトークは、Adrian Trenaman氏の「Removing Friction in the Developer Experience」だった。そこで彼は、開発者が力を十分発揮する妨げになる様々な「摩擦」について語った。「すぐれた開発者体験というのは、アイデアからプロダクションまでの時間を最小化することです」。すぐれたDev-Exを達成するためには、次のことが必要になるという。

「変更をプロダクションへ、頻繁に、迅速に、安全にデプロイでき、その変更の影響を自己管理できるように、組織とアーキテクチャを構築すること」

彼は開発者の要求のヒエラルキーについても説明した。

また、よく引用されるDaniel Pink氏の自律性、熟達、目的にふれ、これらは不足している重要なものだが、私たちは開発者体験にある摩擦も取り除く必要がある、と述べた。

そうして、アイデアからプロダクションまでの時間を遅らせる、様々なタイプの摩擦について説明した。

ステージング環境やテスティング環境 – プロダクションでテストできるようにシステムを構築する必要がある、と彼は語る。プロダクションでのテストについて、ダークカナリア、ローリングリリース、ロールバックを用いるアイデアについて説明した。

技術選択の強制 – 開発者にツールを押し付けるのではなく、開発者にそのコンテキストでもっとも機能するツールを見つけ出す自由を与えて、知識を自由に共有できるようにする。それは広く受け入れられる最善の選択につながるだろう。

壊すことへの恐れ – マイクロサービスを採用し、堅牢性を作り込むことで、失敗から復旧しやすくする。

チーム選択の強制 – チームを強制するのではなく、自己選択のアプローチを導入する。

気を散らすもの – コーディングが第一のアクティビティであることを推し進め、本当に価値があるのか、すべてのミーティングやその他の気を散らすものを精査する。

2番目のトークはTim Bozarth氏の「Zero to Production-Ready in Minutes」だった。

彼のトークの中心は、NetflixのRuntime Platform Teamがいかにして開発者の生産性改善にフォーカスしながら、Netflixが期待する高可用性サービスの構築と維持をより簡単にしているか、だった。彼らはこれを実現するために、他のチームが個々のサービスを構築するために使うプラットフォームとツールを作っている。

彼はこう語る。現状を「ビジネス遂行のコスト」として受け入れるのは間違っている、それは、必要とされる難しい再設計の判断に取り組んでいないために、組織が支払っている税金であることが多い。

そして、開発者がアプリを「舗装された道路」に数分でデプロイできるジェネレーターの作り方についても説明した。– これはベースとなるアプリを用意して環境と統合するのに関するこれまでの課題の多くを克服する。

彼はジェネレーターセッション記録を実際に再生して、どうやって数分でコードと設定の両方を生成し、ベースの構造を提供するかを見せた。これにより、開発者は解決すべき問題にフォーカスできるようになる。ジェネレーターは開発者が土台にするコンポーネントを生成することで、創造性を妨げることなく一貫性を実現する、と彼は語る。

難しいことかもしれないが、手作業のビルドからオープンソースソリューション選択への移行についても語った。彼は次のように指摘した。

「慣性は強力であり、ひどい戦略です」

次のトークはJames Wen氏の「Spotify Lessons: Learning to Let Go of Machines」だった。そこで彼は、開発者にマシンを「ペット」ではなく「牛」として扱わせるSpotifyの変化について説明した。

これは、サーバー向けに個別にカスタマイズしたプラットフォームをあきらめ、コモディティ思考へと移行し、気を散らすものを取り除くことを意味している。フィーチャー開発者がインフラ作業に費やしている時間は、フィーチャーに取り組んでおらず、組織に対する彼らの価値を損なっている、と彼は指摘する。例として、キャパシティプランニングに費やす時間をあげた。これは年間18000もの開発時間になる可能性があるという。

SpotifyにはOps部隊があり、開発者がサービスの構築とデプロイに使うプロダクトを作っている。– フィーチャーチームはOps部隊が書いたツールを用いて、自らのオペレーションとプロビジョニングを行っている。

これを可能にするために、Ops部隊は開発者の懸念を見つけ出し、その懸念を軽減するよう積極的に取り組んだ。

開発者が新しいアプローチに慣れる前に、彼らは克服しなくてはならない様々な課題を見つけ出した。それには次のようなものが含まれる。

• 手動の/退屈なセットアップ
• マシンが準備できるまでの待ち時間（デプロイメントパッケージ、DNSなど）
• 自動でないセキュリティアップデート
• 固定の信頼できるホスト名にすること
• SSHアクセス
• チームが落とさない限り、常に起動/存在する必要性

こうした課題を克服すると、人々（開発者たち）は先に進んで、変更管理の課題になった。彼らは確実にエッジケースを作る必要があった。最小公分母のアプローチは容認されなかったし、きっとうまくいかなかっただろうという。

次のトークは、Michael Bryzek氏の「Production - Designing for Testability」だった。このトークも、テスト環境やステージング環境を捨てることの価値について考えるものだ。最初からテスト可能なプロダクション環境を設計し、プロダクションでテストするアプローチへの移行を支持している。

テスト環境やステージング環境なしに、高品質なソフトウェアを構築できる、と彼は主張する。

「ハイベロシティでハイクオリティなチームが検討すべき最も重要な成果物の一つとして、一流のテスト可能性を作り込んだ、すぐれたマイクロサービスアーキテクチャの基盤を構築する」

Giltでは、高品質なソフトウェアの実現を助けるために、3つのことが行われている。

• 真の継続的デリバリー
• ステージング環境なし
• コードをローカルで実行しない

これを実現するためには、最初から継続的デリバリーを設計し、プロダクトのアーキテクチャにテスト可能性を作り込む必要がある、と彼は指摘する。

彼はこう語る。ステージング環境は偽の万能薬だ。実際には本当の価値をもたらすことなく、セキュリティの幻想を与えてしまう。

• （ステージング環境は）フローにおけるボトルネックの原因になる。
• （ステージング環境は）必然的に脆弱であり、サポートの優先順位が低く扱われる。
• （ステージング環境は）プロダクションとは異なるため、テスト結果は正しくない。
• （ステージング環境は）高価である（通常、予算の30-40%を占める）
• （ステージング環境は）間違ったインセンティブを促す（「私のマシンでは動いている」）

彼はテストファーストのアプローチを重視し、「コードをローカルで実行してはいけない、高品質のテストを書き、テストを実行し、テストを信頼しよう」と開発者にすすめる。

彼はこのアプローチをサポートするために必要なアーキテクチャ上の関心事について説明した。リスクを軽減して、失敗しても影響を最小限にするのだ。それには以下を通した、サービスの徹底的な分離と堅牢性のためのコーディングが必要になる。

• リッチなイベントストリーム
• 独自のDNS/ロードバランサー
• サービス毎にプライベートなデータベース
• 共有状態をなくす
• 失敗が連鎖しないようにする
• 「停止」ではなく「遅延」させるコード

（たとえ自分で構築したとしても）「すべてのサービスはサードパーティのサービスである」という考え方をすることで、1つのサービスの停止に対して適切な方法で対応可能な、より堅牢なコードを構築するのだ。私たちはすでに外部サービスでこれをやっているので、内部サービスに対する思考をこのように移行するのは簡単なはずだ。

物事は間違う可能性があるため、重要な考慮事項がいくつかある、と彼は指摘する。

• プロダクションへのアクセスを、デフォルトではなく明示的にする
• 定義されたパスを使う（たとえばAPI呼び出し）
• 機密性の高いデータを制限する
• 副作用を設計する

Giltでは、このテストファーストのアプローチの予期せぬ副作用は、継続的なテストケースからの最新で正確なドキュメントであることがわかった。

これを達成するためにはツールが重要だと彼は主張する。– 適切なツールを選び、学び、正しく実装しよう。

このトラックの最後のトークは、Erich Ess氏の「Reasoning About Complex Distributed Systems」だった。そこで彼は、システム思考と根本原因分析について紹介した。

彼はまず、複雑なシステムで作業をするのは非常に厄介なことであり、依存関係と相互作用が引き起こす問題をデバッグするには、根本的な振る舞いを考慮して理解するための戦略が必要になると指摘した。彼は（個人的な経験から）ほとんどの開発者は、とりわけ早朝3時に優先度の高い電話を受け取るとき、効果的な推論テクニックを活用していないと主張する。

彼は、開発者（と他の人）がより効果的に問題解決するのに役立つ2つの思考ツールを提案した。 – メンタルモデリングと実験だ。

メンタルモデリングには、複雑なシステムを一連のコンポーネントとして見る必要がある。コンポーネント間の決定/分岐ポイントと引き継ぎポイントが明確になるよう、大きな塊にあるシステムの相互作用をモデル化する。このモデルはシンプルかつ抽象レベルである必要がある。個々のコンポーネントはブラックボックスとして見えて、コンポーネント間で仕事を受け渡すようにする。

一連のフローと、各コンポーネントのシステム全体とのやりとりを特定する。入力がどのように変わるのか、システムがどのように相互作用するか、出力がどのように見えるべきかを考える。後ろ向きに追跡して、期待する動作と実際の動作が異なる箇所を特定し、それにより、どのコンポーネントをさらに詳しく調べるべきか特定する。

1つのコンポーネントの内部を調べるときには、これと同じ推論をサブコンポーネントレベルで用いることで、実際に問題がある箇所を特定することができる。

この推論アプローチと実験という考えを組み合わせることで、仮説が正しいかどうかを即座に明らかにする入力セット（入力を変えると期待される振る舞いが変わる）を設計することができる。もしそうでなければ、もっと検討しよう。もしそうであれば、どこに欠陥があるかわかるかもしれない。

頭の中にある個々の問いに答えて、システムの実際の振る舞いを明らかにするために、テストデータを注意深く設計することが重要である、と彼は強調した。