1.すべてが壊れる
可能な限りストローを敷くようにします。 すべてのデータベースサーバーは100％ミラーリングされています。 データセンターでは、2〜3時間の作業が予定されていますが、この時点でサービスが作業を中断することはありません。 したがって、ミラーは異なるデータセンターに配置され、さらには異なる国に配置されます。 さらに、サーバーに定期的にセキュリティ更新プログラムをインストールする必要があり、場合によっては再起動が必要になります。 このような場合、バックアップサーバーへのホットスイッチが最も歓迎されます。
サーバーはRAIDで、毎日バックアップを行います。 いくつかのアプリケーションサーバーがあり、これによりスケーラビリティが提供され、サービスを中断することなく順番に更新することができます。 負荷を分散するために、ラウンドロビンDNSメカニズムを使用します。 DNSは最も信頼性の高いインターネットシステムであると想定しました。これがないと、サイトが開かないからです。 しかし、ここで驚きが待っていました。
ドメインゾーンを大規模なレジストラregist.comでホストし、300万を超えるドメインにサービスを提供しています。 予想どおり、2つの独立したドメインネームサーバー（ネームサーバー）があり、そのうちの1つを障害から保護しています。 ある朝、両方とも失敗しました。 register.com管理コンソールは使用できませんでした。 Twitterでは、ユーザーのti病な苦情が現れ始め、1時間後には、雪崩のような叫び声、泣き声、うめき声、そしてすぐにこのプロバイダーを去る約束の流れに取って代わられました。 サーバーの電源を入れたらすぐに。
それ以来、ドメインゾーンをAmazonに移動しました。これは、インターネットの異なるルートゾーンにある4つのドメインネームサーバーを提供します：.com、.net、.org、.uk。 これにより、さらなるレベルの信頼性が提供されます。何らかの理由でDNSで.comドメインゾーン全体が利用できない場合でも、クライアントは引き続きサービスを使用できます。
結論：遅かれ早かれコンポーネントが故障することを知ってシステムを設計します。 マーフィーを思い出してください：何らかのトラブルが発生する可能性がある場合、それは間違いなく発生します
2.アプリケーションのボトルネックがわからない
負荷が大きくなると、常に2つのことを行います。メモリ（RAM）を購入し、アプリケーションを最適化します。 しかし、アプリケーションのどの機能が十分に高速でないかを理解する方法は？ 開発者のマシンでのテストでは、合成測定によって判断することは困難です。 プロファイラーを戦闘サーバーで実行することはほとんど不可能です。オーバーヘッドが大きくなりすぎ、サービスの速度が低下し始めます。
コントロールポイントをコードに挿入し、プログラムがそれらの間で実行されるまでにアプリケーションの速度を評価する必要があります。
そのため、プロセッサ時間の1/3が...シリアル化に費やされていることがわかりました：データ構造をJSON文字列にパックします。 代替のシリアル化ライブラリを検討した結果、人気のない決定を下しました。独自のライブラリを作成します。 特定のタスクの実装は、市場で入手可能な最速の代替ソリューションよりも2倍速く動作しました。
ところで、多くの人々は、暗号化が多くのプロセッサリソースを消費すると誤って信じています。 以前は、このプロセスはCPUリソースの最大20％を実際に「食い尽くす」ことができました。 ただし、2010年1月に発売されたWestmereアーキテクチャからは、AES暗号化アルゴリズムの命令がIntelプロセッサの命令セットに含まれています。 したがって、HTTPからHTTPSに実際に切り替えても、プロセッサの負荷は変わりません。
結論：時期尚早に最適化しないでください。 正確な測定値がないと、速度を上げる必要があるという提案が間違っている可能性があります。
3.すべてをテストする
データベース内のテーブルの構造を変更する必要があったら。 この手順では、サービスを停止する必要があるため、最も忙しい時間（週末の夜）にサービスを計画しました。 テストでは、実行時間が1分未満であることが示されました。 サービスを停止し、戦闘サーバーで手順を開始しましたが、1分または10分で作業が完了しませんでした。
場合によっては、プロシージャがテーブル内のクラスタインデックスの再構築を開始し、そのサイズが約1TBであることが判明しました。 小さなテーブルでテストを実施したため、これに気付きませんでした。 手順の完了を待たずに、サービスを開始する必要がありました。 幸いなことに、すべての基本機能は正常に機能しましたが、タスクにファイルを添付することを除いて、通常よりも多少遅くなりました。 数時間後に手順は終了し、100％の作業能力が回復しました。
結論：戦闘に近いデータ量ですべての変更をテストします。 致命的なエラーがないことを確認するために、アプリケーションをビルドするたびに約500の自動テストを実行します。
4.テスト速度は高くなければなりません
毎週アプリのアップデートをリリースしています。 年に数回、テストにもかかわらず、バグがリリースに忍び込みます。これは、小さいながらも不快なものです。 通常、このようなエラーはリリース後10分以内に検出されます。 そのような場合、ホットフィックスをリリースします。
リリースのロールバックを好む人はいませんが、必要な場合もあります。 修正は迅速に行う必要があり、多くの場合、30分以内にエラーの原因を見つけます。 しかし、リリースがバトルサーバーにヒットするためには、ソースコードが自動アセンブリと自動テストを通過する必要があります。 500のテストは20分以上実行されますが、これは十分高速ですが、並列化をさらに強化することでこの時間をさらに短縮する予定です。
テストが遅いと、バグをそれほど迅速に修正できず、テストがなければバグの数は多くなります。
結論：開発者のリソースにお金をspareしまないでください。 自動テスト用の生産的なサーバーを購入してください。自動テストの数は常に増加しています。
5.製品の各機能を使用する必要があります。
良い製品には多くの反復が必要です。 製品には絶えず新しい機能が追加されていますが、めったに使用されない機能をカットする必要がしばしばあります。 彼らには価値がありません。彼らは開発者の時間をサポートに費やし、画面上の余分なスペースを占有します。
良い庭師は毎年春に若い芽を刈り取り、定期的で健康的で美しい樹冠を形成します。
製品には誰も使用しない機能がありますか？ Pyrusではそのようなことは知りません。
経験的に、少なくとも2％のユーザーが各機能を使用するというルールを作成しました。 これは、機能をオフにすると、何十人または何百人もの人々がそれを好まないことを意味します。 私たちは常に同じことをする別の方法を提供しますが、習慣はより強力です。
結論：開発にはいくらかの犠牲が必要です。 GoogleおよびMicrosoft製品のすべての変更が気に入らない人がどれだけいるか想像してみてください。