建築上の誤り
1.実装を設計するが、アーキテクチャソリューションを検索しない
製品のアーキテクチャを説明するために、次のアプローチのうちどれを使用しますか？
オプションA： 「GlassFish、MySQLを使用したApache Felix、およびMongoDBを実行しているJavaストアです。」
オプションB： 「フォールトトレランスのために相互に同期通信を行わない分離ゾーンを持つ3層アーキテクチャがあります。 永続的なデータストレージは、水平分割を使用した統合レプリケーションを使用したリレーショナルデータベースとNoSQLデータベースの組み合わせです。
正解は「B」です。 答え「A」は、いつでもアーキテクチャの実装をよりよく説明していますが、スケーラビリティを意味するものではありません。 コンポーネント（プログラミング言語、オペレーティングシステム、データベース、ハードウェアなど）は、これらのシステムがどのように相互作用するかに応じてスケーリングされます。 スケーラビリティと可用性は空からもたらされるものではありません。 適切な設計によってのみ、必要に応じてソフトウェアソリューションのコンポーネントを簡単に交換できます。
2.エラー分析なしの設計
ハードウェア、ソフトウェア、データセンター、インターネットサービスプロバイダー、プロセス、人、特に人。 システムが適切に設計され、コアサービスまたは顧客セグメントが分離されている場合、各要素の障害の結果は無視できます。 eコマースプラットフォームでの支払いの一時的な無効化は、その後の購入のために製品を検索、表示、またはバスケットに追加する機能を妨げるものではありません。 1つのクライアントからの負荷が非常に高い場合でも、他のすべてのユーザーに障害が発生することはありません。
タイタニック号の死は、プロジェクト全体を犠牲にする設計エラーの最も有名な例の1つです。船の区画は完全に隔離されておらず、船が船首を転がしたとき、水があふれるまで隔壁に水が流れました。
3.負荷分散の代わりに垂直スケーリング
多くの製品は、依然としてプライマリリポジトリとしてリレーショナルデータベース（MySQL、Oracle、SQL Serverなど）に依存しています。 多くの企業は、多数の小さなデータベース（費用対効果を高めるためにそれぞれが複数のクライアントでホスティングする）でクライアントをセグメント化する代わりに、モノリシックシステムを拡張するために高価で高性能な機器に依存しています。
このような「解決策」は、最終的には、企業の成長に伴う障害発生時の取引コストの増加と損害の増加につながります。 さらに、かさばるシステムは負荷が徐々に大きくなるまでアイドル状態のままになるため、投資効率は低くなります。 最終的に、最大のシステムは十分な大きさではなく、製品にはまだ問題があります。 eBay 1999または2004年のPayPalを考えてください。
4.間違ったツールを使用する
あなたの浴室を修理するために大工を招待してください、そして、彼はハンマーで来ます。 あなたはおそらく結果に満足しないでしょう。 これは、データベースの専門家に製品アーキテクチャの支援を依頼するのと同じです。 リレーショナルデータベースは依然として主要なデータベースであり、 ACID要件または関連データ（たとえば、組織階層を示す製品、階層的な製品カタログなど）を厳守する必要があるソリューションの保存に最適です。 ただし、データの種類に基づいて分散ストレージを作成するための多くの選択肢があります。 したがって、JSON形式のデータがある場合、ドキュメントリポジトリが最適なソリューションになります。 自然な形式でのデータの保存は、追加のテクノロジーを導入およびサポートするオーバーヘッドと常にバランスが取れている必要があります。
組織の失敗
5.機能分離
過去にソフトウェアを作成して販売したとき、機能マネージャーの役割は、すべての気晴らしを中和し、タスクに最大限に集中できるように機能部門を完全に分離することでした。 各チームが高度に専門化された焦点を持っていて、作業の結果が組立ラインに移されたとき、それは良かったです。 今日のSaaS企業はサービスを作成し、ソリューションの変更は2週間に1回、場合によっては1日に数回行われます。 これにより、製品管理者はエンジニアと頻繁に話し合う必要があり、インフラストラクチャエンジニアはコーディングを開始する前であっても対応する必要があります。 機能組織は、品質の低下、市場参入の遅延、イノベーションのレベルの低さ、機能チーム間の対立につながることがあります。 今日の最高のチームは、学際的で自律的で、アイデアの生成からサポートまでのサービスを制御しています（William McDonoughの「クレードルからクレードルまで」のサービスの開発の設計原則に従って）。 この原則を疑う場合は、「危機の際に私たちは何をしますか？」と自問してください。 ほとんどの場合、答えは次のようになります。「さまざまなチームから人々を集め、部屋に閉じて、問題の解決を依頼します。」 これが危機的状況で重要な場合、なぜそれを毎日やらないのでしょうか？
6.大きすぎるチーム
組織のスケーリングにおけるもう1つの重要な間違いは、同じコードで作業する人が多すぎることです。 15〜20人を超えるエンジニアのチームがいる場合、それらのチームとコーディネーションとのつながりが損なわれ始めます。 リソースの計画、従属、および意思決定において意見の相違が生じます。 これらの競合は、新しい機能の生産に割り当てられる時間を要し、顧客にとっての製品の価値を低下させます。
サービスの障害の分離（アーキテクチャについては2ページを参照）は、これらの競合を中和する自然な分割を製品に作成できます。 チームが複数のサービス（ログイン、登録、検索）を担当するのは良いことですが、2つのチームが同じサービスを担当するべきではありません。
7.庭の手入れができない
優秀なマネージャーは、常に従業員の「庭」に種をまき、水をまき、雑草を取り除きます。彼らは新しい才能を集め（種まき）、チームメンバーを育て（水やり）、必要に応じて彼らを去らせます（除草）。 最良の結果を得るには、チームを常に評価する必要があります。 従業員の生産性を、スキル、成長、行動の3つの分野で分析したいと考えています。 スキルのカテゴリーは、彼らが雇われた役割をどれだけ知っていて、果たすかです。
Java開発者である場合、Javaでのコーディングはどの程度ですか？ 成長カテゴリ-同僚は現在の役割を超える機会がありますか。 それらのいくつかは、シニア開発者になる準備ができていますか？ 彼らは建築家になれますか？ 彼らは進んでリードできますか？ 最後のカテゴリは動作です。 行動は会社の文化とどのように一致しますか？ この見過ごされがちなカテゴリは、チーム全体に最大の悪影響を及ぼします。 従業員は優れたJava開発者であり、スケーラブルなシステムの世界で最高のアーキテクトになることができますが、チームの他のメンバーをやる気にさせたり干渉したりする場合は、雑草のように処分する必要があります。
プロセスが失敗しました
8.勉強できない
「歴史の過ちから学ぶことができない人はそれを繰り返す運命にある」というサンタヤンの預言的なフレーズは、組織や製品にも当てはまります。 失敗の結果、サービスが利用できなくなったことが判明しました。その操作性のみを復元したい場合、結論を導き、新しいことを学ぶ素晴らしい機会を逃しています。 それぞれの失敗は、過去の過ちを繰り返さない言い訳と見なされるべきです。 時間をかけて徹底的な調査を行うには、自己規律が必要です。 サービスを切断する理由がハードウェア障害であると思われる場合は、間違いなく見落としていました。 アーキテクチャ、人、プロセスの根本原因を発見するまで、「なぜ？」
9.万能薬としてのアジャイルへの信仰
柔軟な開発方法論は素晴らしいことですが、その使用はチームの構造（組織の障害のセクションの段落5および6を参照）またはビジネス部門（製品部門と営業部門間のコミュニケーションなど）の問題を解決しません。 ソフトウェア開発の理論だけでなく、ビジネスプロセスの一部としてアジャイルを理解することは成功に不可欠です。 最後に、アジャイルは意図されている問題のいくつかを修正できます。 彼女に特定の日付の具体的な結果の保証を期待することは、大工があなたの浴室を修理するという期待に似ています（建築上の誤りのポイント4を参照）。
10.負荷とパフォーマンスのテストは、スケーリングのすべての問題を示します
あなたの会社がサイバー月曜日など、年に1回実行されるシステムに依存している場合、パフォーマンスのストレステストを実施するためにすべての資金を管理する必要があります。 ただし、検証の問題は、ユーザーの意図したアクションで実行されることです。 これは、ソフトウェアが変更されないかどうかをテストするための非常に効果的な方法です。 しかし、ほとんどの企業では、ソフトウェアは頻繁に変更されるため、顧客の行動は頻繁に変更されます。 検索ボタンの色を変更すると、顧客はより重いレポートを実行するか、2倍のリクエストを行います。 言い換えれば、彼らの行動は部分的に予測不可能です。 また、テストでは現在のバージョンとベースバージョンを比較するため、中間バージョンが最新バージョンとどのように相関するかを考えてください。 テスト結果がすべての可能な失敗を示すと信じてはいけません。 代わりに、クライアントを分離ゾーンに分割すると（アーキテクチャの問題については条項2を参照）、少数のユーザーグループ向けに更新プログラムを展開し、新しいテストソフトウェアで実際のクライアントの動作を使用できます。
本を読むことをお勧めします。 本の著者は教義を説明しませんでしたが、私たちの最高の人でさえ時々忘れることができる微妙な点を指摘しました：
- 正しく選択および適用されたツールと方法論。
- チームの有能な管理;
- 以前の経験に依存。
このようなトライアドは、ソフトウェア製品の成功に十分ですか？
以前の投稿：
開発技術について：
再び7つのコア開発方法論について 。
システムスケーリングのトップ10の間違い
8人の命を救う設計原則
カスタムソフトウェア開発における5つの主なリスク 。