トップ ファカポフ シアン

すべての人に良い！ 

私の名前はニキータです。Cian エンジニアリング チームのチーム リーダーです。 会社での私の責任の XNUMX つは、本番環境のインフラストラクチャに関連するインシデントの数をゼロに減らすことです。
以下で説明する内容は私たちに多大な苦痛をもたらしました。この記事の目的は、他の人が私たちの間違いを繰り返さないようにするか、少なくともその影響を最小限に抑えることです。 

プリアンブル

昔、Cian がモノリスで構成されており、まだマイクロサービスの気配がなかった頃、私たちは 3 ～ 5 ページをチェックすることでリソースの可用性を測定していました。 

彼らは答えます - すべて問題ありませんが、長時間答えない場合は - 警告します。 事件とみなされるためにどれくらいの期間仕事を休まなければならないかは、会議で人々が決定した。 エンジニアのチームが常に事件の調査に関与していました。 調査が完了すると、彼らは事後分析、つまり何が起こったか、調査がどれくらい続いたか、現時点で何をしたか、将来何をするかという形式のレポートを電子メールで書きました。 

サイトのメインページ、またはサイトが最下位に達したことをどのように理解しているか

 
エラーの優先度を何らかの方法で理解するために、ビジネス機能にとって最も重要なサイト ページを特定しました。 これらを使用して、成功/失敗したリクエストとタイムアウトの数をカウントします。 これが稼働時間を測定する方法です。 

サイトには、検索と広告の送信という主要なサービスを担当する非常に重要なセクションが多数あることがわかったとします。 失敗したリクエストの数が 1% を超える場合、これは重大なインシデントです。 ゴールデンタイムの 15 分以内にエラー率が 0,1% を超えた場合も、これは重大インシデントとみなされます。 これらの基準はほとんどのインシデントをカバーしますが、残りはこの記事の範囲外です。

トップベストインシデント Cian

したがって、私たちは事件が起こったという事実を判断することを間違いなく学びました。 

現在、あらゆる出来事が詳細に説明され、Jira エピックに反映されています。 ちなみに、このために私たちは FAIL という別のプロジェクトを開始しました。そのプロジェクトではエピックのみを作成できます。 

過去数年間のすべての失敗を収集すると、リーダーは次のとおりです。 

• mssql 関連のインシデント。
• 外部要因によって引き起こされるインシデント。
• 管理者のエラー。

管理者の間違いやその他の興味深い失敗をさらに詳しく見てみましょう。

XNUMX 位 – 「DNS 内を整理する」

嵐の火曜日でした。 DNS クラスター内の順序を復元することにしました。 

内部DNSサーバーをバインドからpowerdnsに転送し、DNS以外に何もない完全に別のサーバーを割り当てたいと考えていました。 

DC の各場所に XNUMX 台の DNS サーバーを配置し、ゾーンをバインドから powerdns に移動し、インフラストラクチャを新しいサーバーに切り替える時期が来ました。 

移動の最中、すべてのサーバー上のローカル キャッシュ バインドで指定されたすべてのサーバーのうち、サンクトペテルブルクのデータ センターにある XNUMX 台だけが残りました。 この DC は当初、私たちにとって重要ではないと宣言されていましたが、突然単一障害点になってしまいました。
モスクワとサンクトペテルブルクの間の運河が崩落したのはこの移転期間中にあった。 実際、DNS が使用できない状態で XNUMX 分間放置されましたが、ホスティング業者が問題を解決したときに復旧しました。 

結論：

以前は仕事の準備中に外部要因を無視していましたが、今ではそれらも準備中のリストに含まれています。 そして現在、すべてのコンポーネントが n-2 で予約されていることを確認するよう努めており、作業中にこのレベルを n-1 に下げることができます。

• アクションプランを作成するときは、サービスが失敗する可能性があるポイントをマークし、すべてが「悪化から悪化」するシナリオを事前に検討してください。
• 内部 DNS サーバーをさまざまな地理的位置/データセンター/ラック/スイッチ/入力に分散します。
• 各サーバーにローカル キャッシュ DNS サーバーをインストールします。このサーバーは要求をメイン DNS サーバーにリダイレクトします。サーバーが使用できない場合は、キャッシュから応答します。 

XNUMX位 – 「Nginxで物事を整理する」

ある晴れた日、私たちのチームは「これにはもう飽きた」と判断し、nginx 構成をリファクタリングするプロセスが始まりました。 主な目標は、構成を直感的な構造にすることです。 以前は、すべてが「歴史的に確立」されており、何の論理もありませんでした。 これで、各server_nameが同じ名前のファイルに移動され、すべての構成がフォルダーに分散されました。 ちなみに、この設定には 253949 行または 7836520 文字が含まれており、約 7 MB を占めます。 最上位の構造: 

Nginxの構造

├── access
│   ├── allow.list
...
│   └── whitelist.conf
├── geobase
│   ├── exclude.conf
...
│   └── geo_ip_to_region_id.conf
├── geodb
│   ├── GeoIP.dat
│   ├── GeoIP2-Country.mmdb
│   └── GeoLiteCity.dat
├── inc
│   ├── error.inc
...
│   └── proxy.inc
├── lists.d
│   ├── bot.conf
...
│   ├── dynamic
│   └── geo.conf
├── lua
│   ├── cookie.lua
│   ├── log
│   │   └── log.lua
│   ├── logics
│   │   ├── include.lua
│   │   ├── ...
│   │   └── utils.lua
│   └── prom
│       ├── stats.lua
│       └── stats_prometheus.lua
├── map.d
│   ├── access.conf
│   ├── .. 
│   └── zones.conf
├── nginx.conf
├── robots.txt
├── server.d
│   ├── cian.ru
│   │   ├── cian.ru.conf
│   │   ├── ...
│   │   └── my.cian.ru.conf
├── service.d
│   ├── ...
│   └── status.conf
└── upstream.d
    ├── cian-mcs.conf
    ├── ...
    └── wafserver.conf

かなり改善されましたが、構成の名前を変更して配布する過程で、一部の構成の拡張子が間違っており、 include *.conf ディレクティブに含まれていませんでした。 その結果、一部のホストが利用できなくなり、メイン ページに 301 が返されました。 応答コードが 5xx/4xx ではなかったため、これはすぐには気づかれず、朝になって初めて気づきました。 その後、インフラストラクチャ コンポーネントをチェックするテストの作成を開始しました。

結論： 

• (nginx に限らず) 構成を正しく構造化し、プロジェクトの初期段階でその構造についてよく考えてください。 こうすることでチームにとって理解しやすくなり、結果的に TTM が削減されます。
• 一部のインフラストラクチャ コンポーネントのテストを作成します。 たとえば、すべてのキーのserver_nameが正しいステータスと応答本文を提供していることを確認します。 コンポーネントの基本機能をチェックするスクリプトをいくつか手元に用意しておけば、午前 3 時に他に何をチェックする必要があるかを必死になって思い出す必要がなくなります。 

XNUMX位 - 「カサンドラのスペースが突然なくなった」

データは着実に増加し、圧縮が機能しなかったため、Cassandra クラスターで大規模なケーススペースの修復が失敗し始める瞬間まではすべてが順調でした。 

ある嵐の日、塊はほとんどカボチャに変わりました。

• クラスターには合計スペースの約 20% が残っていました。
• パーティション上のスペース不足によりノードの追加後にクリーンアップが実行されないため、ノードを完全に追加することはできません。
• 圧縮が機能しないため、生産性は徐々に低下します。 
• クラスターは緊急モードになっています。

終了 - クリーンアップせずにさらに 5 つのノードを追加しました。その後、スペースがなくなった空のノードのように、それらをクラスターから体系的に削除して再入力し始めました。 私たちが望んでいたよりもはるかに多くの時間が費やされました。 クラスターが部分的または完全に利用できなくなるリスクがありました。 

結論：

• すべての cassandra サーバーで、各パーティション上のスペースの 60% を超えて占有してはなりません。 
• CPU の 50% 以下でロードする必要があります。
• キャパシティプランニングを忘れずに、コンポーネントごとに、その詳細に基づいて検討する必要があります。
• クラスター内のノードが多いほど良いです。 少量のデータを含むサーバーはすぐに過負荷になり、そのようなクラスターは復活しやすくなります。 

XNUMX位 - 「領事のキー/値ストレージからデータが消えた」

サービスの発見には、多くの人と同様に consul を使用します。 ただし、モノリスの青と緑のレイアウトにもその Key-Value を使用します。 アクティブおよび非アクティブなアップストリームに関する情報が保存され、展開中に場所が変わります。 この目的のために、KV と対話する展開サービスが作成されました。 ある時点で、KV のデータが消えてしまいました。 メモリから復元されましたが、多数のエラーがありました。 その結果、アップロード中にアップストリームの負荷が不均一に分散され、バックエンドの CPU に過負荷がかかるために多くの 502 エラーが発生しました。 その結果、私たちは consul KV から postgres に移行し、そこからそれらを削除するのはそれほど簡単ではなくなりました。  

結論：

• 許可のないサービスには、サイトの運営に重要なデータが含まれていてはなりません。 たとえば、ES で権限がない場合は、必要のないところからのアクセスをネットワーク レベルで拒否し、必要なものだけを残し、さらに action.destructive_requires_name: true を設定するとよいでしょう。
• バックアップとリカバリのメカニズムを事前に練習してください。 たとえば、バックアップと復元ができるスクリプトを事前に（たとえば Python で）作成します。

XNUMX位「キャプテン・アンオブビアス」 

ある時点で、バックエンドに 10 台以上のサーバーがある場合、nginx アップストリームの負荷が不均一に分散していることに気づきました。 ラウンドロビンではリクエストが最初から最後のアップストリームに順番に送信され、nginx のリロードが行われるたびに最初からやり直しになるため、最初のアップストリームは常に残りのアップストリームよりも多くのリクエストを受信し、その結果、動作が遅くなり、サイト全体に影響が生じました。 これは、トラフィック量が増加するにつれてますます顕著になりました。 単純に nginx を更新してランダムを有効にするだけでは機能しませんでした。バージョン 1 (現時点では) で成功しなかった大量の lua コードをやり直す必要があります。 nginx 1.15 にパッチを適用して、ランダムなサポートを導入する必要がありました。 これで問題は解決しました。 このバグは「Captain Non-Ovviousness」カテゴリを獲得しました。

結論：

このバグを調査するのは非常に興味深く、刺激的でした)。 

• このような変動をすぐに発見できるようにモニタリングを整理します。 たとえば、ELK を使用して、各アップストリームの各バックエンドの RPS を監視し、nginx の観点から応答時間を監視できます。 この場合、これは問題を特定するのに役立ちました。 

結果として、やっていることに対するより綿密なアプローチがあれば、ほとんどの失敗は回避できたはずです。 私たちはマーフィーの法則を常に覚えておく必要があります。 うまくいかない可能性のあるものはすべてうまくいかないし、 そしてそれに基づいてコンポーネントを構築します。 

出所： habr.com