敏ility性は安全でなければなりません

Eugene（Jim）Brickmanは、「Hello、Startup」という本の著者であり、スタートアップ支援を専門とするAtomic Squirrelの創始者です。 それ以前は、Linkedln、トリップアドバイザー、Cisco Systems、Thomson Financialなどの企業で10年以上働いていました。 また、コーネル大学でコンピューターサイエンスの学士号と修士号を取得しています。



あなたの仕事は、高速道路のすべての車をより速くすることだと想像してください。 すべてのドライバーにアクセルペダルを最後まで押すように指示した場合はどうなりますか？



明らかに、結果は災害になります。 しかし、これはまさに、多くの開発者が実装しようとしている関係のタイプであり、ソフトウェアをより速く作成しようとしています。 これを行う理由のいくつかを以下に示します。



「私たちは本当にダイナミックになろうとしているので、構造やドキュメントを開発するために無駄に時間を無駄にしないでください。」

「すぐに実稼働環境に送信する必要があるため、テストを書く時間がありません！」

「何も自動化する時間がなかったので、コードを手動でデプロイするだけでした。」



高速道路の車の場合、高速での走行には安全性に特に注意が必要です。 車を素早く運転できるようにするには、ブレーキ、ベルト、エアバッグなどの適切なデバイスが必要です。これにより、何か問題が発生した場合にドライバーを救うことができます。



ソフトウェアの場合、アジリティにはセキュリティも必要です。 合理的な妥協に到達することと、注意を払うことなく盲目的に前進することには違いがあります。 有害事象が発生した場合の損失を最小限に抑える安全メカニズムが必要です。 無謀な人は、最終的には速くなるのではなく、遅くなります：



•テストを書かずに「保存」された1時間は、本番エラーの原因となる間違いを見つけるのに5時間かかり、「パッチ」が新しいエラーを生成した場合はさらに5時間かかります。



•30分間ドキュメントを作成する代わりに、各従業員にプログラムの使用方法を1時間教え、従業員が製品を誤って使用し始めたかどうかを調査するのに何時間も費やします。



•自動化を心配せずに少し時間を節約できますが、コードを手動で再入力するのに時間がかかり、誤ってステージを見逃した場合はエラーを検索するのにさらに時間がかかります。



ソフトウェアの世界の主要なセキュリティメカニズムとは何ですか？ この記事では、自動車の世界における3つの安全メカニズムと、プログラムの世界における同様のメカニズムを紹介します。

ブレーキ/継続的統合

問題が本当に深刻になる前に、良いブレーキは車を止めます。 ソフトウェアでは、継続的インテグレーションにより、間違ったプログラムが実稼働に入る前に停止します。 「継続的インテグレーション」という用語を理解するために、最初にその反対であるレイトインテグレーションを検討します。





図 1.国際宇宙ステーション



図に示すように、多くのコンポーネントで構成される国際宇宙ステーション（ISS）を構築する責任があると想像してください。 1.さまざまな国のチームがこれまたはそのコンポーネントを作成する必要があり、すべてを編成する方法を決定します。 次の2つのオプションがあります。



•すべてのコンポーネントを事前に開発します。その後、各チームは完全に独立してコンポーネントを離れます。 すべてのコンポーネントの準備ができたら、それらをすべて一緒に宇宙に発射し、一緒にしようとします。



•すべてのコンポーネントの初期初期設計を開発し、その後各チームが作業を開始します。 各チームは、コンポーネントを開発しながら、各コンポーネントを他のコンポーネントと継続的にテストし、問題が発生した場合はアプローチ、構造、設計を変更します。 準備の構成要素は単独で空間に移動し、そこで組み立てられます。



オプション1では、最後にISS全体を収集しようとすると、多数の競合と設計上の問題が発生します。フランスの配線はフランスが行うべきであり、後者はこれがイギリスの仕事であると確信していたが、 突然、すべてのチームがメトリック測定システムを使用したことが判明しましたが、1つはイギリス人です。 トイレを設置する作業を自分たちにとって重要と考えたチームは1つもありませんでした。 すべてがすでに行われ、宇宙を飛び回っているときにすべてを明らかにすることは、問題の解決が非常に困難で高価になることを意味します。



残念ながら、これは多くの企業がソフトウェアを作成するときに使用するパスです。 開発者は、数週間または数か月間、それぞれの分野で絶えず完全に独立して行動し、最後の最後で出力製品に開発を統合しようとします。 このプロセスは「後期統合」と呼ばれ、マージの競合（図2を参照）、検出困難なエラーの検索、プロジェクトの出力（リリース）ブランチの安定化の試みを解決するための時間（日、週）の大幅な損失につながることがよくあります。





図 2.機能ブランチをプロジェクトの出力（リリース）ブランチにまとめると、深刻なマージ競合が発生します



オプション2として説明されている代替アプローチは、すべての開発者が定期的に作業の結果をまとめる、継続的な統合です。 これにより、開発者が間違った方向に移動しすぎる前にプロジェクトの問題を特定し、開発の一貫した開発を可能にします。 継続的に統合する最も一般的な方法は、ステム開発モデルを使用することです。



このモデルでは、開発者はバージョン管理システム（バージョン管理システム= VCS）に応じて、「トランク」または「マスター」と呼ばれる同じブランチですべての作業を行います。 アイデアは、誰でも定期的にこのスレッドに自分のコードをアップロードすることであり、おそらく1日に数回です。 単一のブランチでのすべての開発者の作業は本当に価値がありますか？ ステム開発は、LinkedIn、Facebook、Googleの何千人ものプログラマーによって使用されています。 Googleのトランク（「トランク」）統計は特に印象的です。毎日1つのブランチで、20億行を超えるコードと45,000を超える確認操作を調整しています。



図 3.ステミングでは、それぞれが同じブランチに独自のコードをアップロードします。



多くの場合、何千人もの開発者が競合せずに同じブランチにコードをアップロードできますか？ 頻繁に小さな確認操作を頻繁に行うと、巨大なモノリシックな合併を実行する代わりに、競合の数は非常に少なく、発生する競合が望ましいことがわかります。 これは、使用される統合戦略に関係なく競合が避けられないという事実によるものですが、1か月から2日間の作業（継続的な統合を伴う）を表す競合は、数か月の作業を表す競合（統合が遅い）よりも簡単に解決できます。



そして、ブランチの安定性はどうですか？ すべての開発者が同じブランチで作業し、開発者がコンパイルしないか重大なエラーを引き起こすコードをダウンロードすると、プロセス全体がブロックされる可能性があります。 これを防ぐには、セルフテストレイアウトが必要です。 自己テストレイアウトは完全に自動化されたプロセスです（つまり、1つのコマンドで開始できます）。十分な数の自動テストが含まれています。 それらがすべて合格すれば、コードの安定性を確認できます。 通常のアプローチは、確認操作フックをバージョン管理システム（VCS）に追加します。VCSは、このような各操作を受け入れ、JenkinsやTravisなどの継続的統合（CI）サーバー上のリンクを介して渡し、拒否します。レイアウトが失敗した場合。 CIサーバーはコントローラーであり、コードの各バッチをチェックしてから、トランクにロードできるようにします。 良いブレーキのように動作し、本番に入る前に悪いコードを止めます。



継続的インテグレーションなしでは、誰かが動作することを示すまで、ソフトウェアは壊れているとみなされます。これは通常、テストまたはインテグレーションの段階で発生します。 継続的インテグレーションでは、新しい変更のたびにソフトウェアが動作すると信じられています（もちろん、かなり包括的な自動テストのセットがない限り）-開発者は違反が発生した瞬間を知っているため、エラーをすぐに修正できます。

-Jez HumbleyとDavid Farley、本Continuous Delivery（Continuous Delivery of Software）の著者



継続的インテグレーションを使用して大きな変更を加えるにはどうすればよいですか？ つまり、1週間を必要とする機能に取り組んでいる場合、1日に何度もトランクにアップロードできますか？ 1つの解決策は、機能の切り替えを使用することです。

安全ラッチ/機能スイッチ

19世紀初頭、ほとんどの人はエレベーターを避け、ケーブルが壊れるとエレベーターの乗客が死ぬことを恐れていました。 この問題を解決するために、エリシャオーティスは「安全なエレベーター」を発明し、その有効性を大胆に実証しました。 これを行うために、オーティスは大きなオープンエレベータシャフトを構築し、オープンエレベータを数階持ち上げて、アシスタントに聴衆の前でケーブルを切るように命じました。 4.エレベーターは落下し始めましたが、すぐに停止しました。





図 4.エリシャ・オーティスは「安全なリフト」を実証します。



どのように機能しますか？ 安全エレベーターの重要な要素は、図1に示す安全ラッチです。 5.初期位置では、安全ラッチは完全に伸びており、エレベータシャフトのラッチに入り、エレベータが動かないようになっています。 エレベータケーブルが十分に締められている場合にのみ、安全ラッチが外れます。 言い換えれば、ラッチはケーブルが無傷の場合にのみ格納されます。





図 5.安全エレベーターの特許の図は、中央にエレベーターがあり（D）、側面に安全ラッチがあり（f）、上部にケーブルがある（G）エレベーターシャフトを示しています。



この素晴らしいデザインでは、安全ラッチはデフォルトでセキュリティを提供します。 ソフトウェアでは、パフォーマンススイッチは同じ機能を実行します。 機能スイッチを使用する方法は、構成ファイルまたはデータベースで名前付き機能スイッチ（showFeatureXYZなど）を検索する「if」ステートメントですべての新しいコードをラップすることです。



if（featureToggleEnabled（“ showFeatureXYZ”））{showFeatureXYZ（）}



重要な考え方は、デフォルトでは、すべての機能スイッチがオフの位置にあるということです。 つまり デフォルトの位置は安全です。 つまり、特性スイッチのシェルが有効になっている間、「if」演算子はコードが実行されない、または目に見える効果がないことを保証するため、不完全なコードまたは誤ったコードをロードして終了することもできます。

特性の作業が完了したら、指定したスイッチ特性を「オン」の位置に配置できます。 これらのスイッチの特性と値を構成ファイルに保存する最も簡単な方法。 したがって、開発環境の構成でこの機能を有効にできますが、完了するまで使用されないようにすることができます。



# config.yml

dev:

showFeatureXYZ: true



prod:

showFeatureXYZ: false









より強力なオプションは、各ユーザーの特性スイッチの値を設定できる動的システムの存在と、従業員が特性スイッチの値を動的に変更して特定のユーザーの特定の特性を有効または無効にすることができるユーザーWebインターフェイスの存在です図に示す。 6。

たとえば、開発中、最初は会社の従業員にのみいくつかの特性を許可できます。 機能が完成したら、すべてのユーザーの1％に対して有効にすることができます。 すべてが正常であれば、10％のユーザーに許可を与え、次に50％に許可を与えることができます。 ある時点で問題が発生した場合、Webベースのユーザーインターフェイスを使用して、問題の機能をオフにすることができます。 パフォーマンススイッチは、ベンチマークにも使用できます。





図 6. LinkedIn XLNT機能オフツールを使用して、米国ユーザーの1％に対して一部の機能を有効にする

バルクヘッド/ソースコードベースのパーティション分割

船舶では、隔壁を使用して、断熱された防水コンパートメントを作成します。 このため、ケースが破壊されると、1つのコンパートメントのみが殺到します。

同様に、ソフトウェアでは、ソースコードベースを分離されたコンポーネントに分割することができます。そのため、問題が発生した場合、このコンポーネント内でのみ動作します。

ソースコードベースの最悪の特性は大きすぎるため、ソースコードベースのパーティション分割は重要です。 プログラムが大きいほど、開発は遅くなります。 たとえば、Steve McConnellの著書「Perfect Code」（Steve McConnellの「Code Complete」、2004年）のタブレットを考えてみましょう。プロジェクトのサイズ（コード行）とエラー密度（コード1000行あたりのエラー数）の関係を示します。











ここでは、コードベースが増加するにつれて、エラーの密度が増加することがわかります。 ソースコードベースが2倍に増加した場合、エラーの数は4〜8倍に増加します。 また、50万を超えるコード行を処理する必要がある場合、エラー密度は10行ごとに1つのエラーに達する可能性があります。



その理由は、アンディ・ハントの著書である 『Venkat Subramaniam』の引用を使用すると、高速ソフトウェア開発に関するエチュードだからです。 「-」ソフトウェア開発は、統合開発環境や設計ツールではなく、どのスキームでも行われません。 それはあなたの頭の中で起こります。」 数十万のコード行を含むソースコードデータベースは、人が心に留めておくことができるものをはるかに超えています。 このような巨大なプログラムのすべての相互作用とデッドロックを考慮することは不可能です。 したがって、プログラムを分割して、特定の瞬間にプログラムの一部に集中し、他のすべてを安全に残すことができるようにする戦略が必要です。



コードベースを分割するには、主に2つの戦略があります。1つは人為的な機能への依存関係の導入であり、もう1つはマイクロサービスアーキテクチャの導入です。



人工的な機能への依存性の考え方は、他のモジュールのソースコードに依存する代わりに（ソースの依存性）、他のモジュールによって発行されたバージョン管理された人工的な機能に従うようにモジュールを変更することです（人工的な機能への依存性）。 あなたはすでにオープンソースライブラリでこれをしているかもしれません。 JavaScriptプログラムでjQueryを使用するか、JavaコードでApache Kafkaを使用するには、対応するオープンソースライブラリのソースコードに依存せず、これらのライブラリが提供するバージョン管理された人工属性（jquery-1.11-min.jsまたはkafkaなど）に依存します-clients-0.8.1.jar。 各モジュールの固定バージョンが使用されている場合、開発者がそのようなモジュールに対して行った変更は、明示的に更新を選択するまで影響しません。 このアプローチは、船舶の隔壁のように、他のコンポーネントの問題からあなたを隔離します。



マイクロサービスの考え方は、すべてのモジュールが同じプロセスで動作し、機能呼び出しを介して通信する単一のモノリシックアプリケーションから、各モジュールが個別のプロセスで動作する分離サービスに切り替えることです。メッセージ。 サービスの境界はソフトウェア所有権の境界として機能するため、マイクロサービスはチームが独立して作業できるようにする優れた方法です。 マイクロサービスを使用すると、さまざまなテクノロジーを使用して製品を作成することもできます（たとえば、1つのマイクロサービスをPythonで、別のマイクロサービスをJavaで、3つ目をRubyで）、各サービスを独立して評価できます。



人工的な機能とマイクロサービスへの依存性には多くの利点がありますが、多くの重大な欠点も含まれています。どちらの方法も、前述の継続的統合のアイデアと矛盾して機能します。 トレードオフの詳細については、「コードベースをマイクロサービスとアーティファクトに分割する」（「 マイクロサービスと人工特性アプローチにおけるソースコードベースの分離」）を参照してください。

3つの質問

セキュリティメカニズムを使用すると、より迅速に移行できますが、すべての費用を支払う必要があります。開発が実際に遅くなる場合、事前の時間が必要です。 現在の製品のセキュリティメカニズムに費やす価値がある時間を決定する方法は？ 決定を下すには、次の3つの質問をする必要があります。



•問題のメカニズムによって対処される問題のコストはいくらですか？

•セキュリティメカニズム自体の価格はいくらですか？

•これらの問題はどの程度発生する可能性がありますか？



この記事を終了するために、一般的なソリューションで上記の3つの質問がどのように機能するかを見てみましょう。自動テストを行うかどうかです。



頑固なテスト愛好家の中には、すべてに対してテストを作成し、100％のコードカバレッジを目指して努力する必要があると主張する人もいますが、現実の世界ではこれに近いものを見ることは非常にまれです。 Hello、Startupを書いたとき、Google、Facebook、LinkedIn、Twitter、Instagram、Stripe、GitHubなど、過去10年間で最も成功したスタートアップの開発者にインタビューしました。 特に初期の段階で、チェックするものとチェックしないものについて、全員が慎重に考え抜いた妥協案を作成したことが判明しました。



これらの3つの質問を検討してください。

自動化されたテストの作成と保守のコストはいくらですか？

単体テストの準備は現在安価です。 高品質のテストプラットフォームは、ほぼすべてのプログラミング言語で使用できます。 ほとんどの建物システムには、単体テストのサポートが組み込まれており、通常は迅速に機能します。 一方、統合テスト（特にユーザーインターフェイステスト）では、システムの重要な部分を使用する必要があります。つまり、構成に費用がかかり、作業が遅く、保守が難しくなります。



もちろん、統合テストでは、単体テストでは見落とされる多くのエラーをキャッチできます。 しかし、セットアップと実装は非常に高価であるため、ほとんどのスタートアップは固定資産を非常に複雑な単体テストに振り向け、非常に価値のある重要な統合テストの小さなセットに少しだけ投資することが判明しました。

自動化されたテストがない場合に合格できるエラーのコストはいくらですか？

1週間以内に捨てる可能性が高いプロトタイプを作成する場合、エラーのコストは低いため、テストに投資する価値はおそらくありません。 一方、支払い処理システムを作成する場合、エラーのコストは非常に高くなります。もちろん、クライアントのクレジットカードから2回引き落としたり、間違った金額で操作したりすることは望ましくありません。



私が開発者と話し合った新興企業はテストのやり方が異なりましたが、ほとんど全員がコードのいくつかの部分（通常は支払い、セキュリティ、データストレージ）を自ら決定しましたが、違反は単に容認できないため、深刻なチェックが行われました文字通り初日から。

自動テストなしでエラーが発生する可能性はどのくらいですか？

上に示したように、コードベースが大きくなると、エラーの密度が増加します。 同じことが、チームの規模とプロジェクトの複雑さの増大にも当てはまります。



10,000行のコードを持つ2人のプログラマのチームの場合、テストの作成に費やす時間のわずか10％で十分です。 20人のプログラマと100,000行のコードを使用すると、これには20％の時間がかかり、100万行の200人のコード開発者のチームでは50％が必要になります。



プログラムのサイズと開発者の数が増えるにつれて、テストにより多くの時間を費やす必要があります。