ゲスト紹介

張冠宇：通称「関羽」。現在はDianpingでオペレーションアーキテクトとして勤務。Dianping在籍中、彼は同社のオペレーションが「ゼロ」から「有意義」へ、そして「非効率」から「効率的」へと変貌していく過程を目の当たりにしてきた。

共有コンテンツ

今日は、画像に示すように、次の 5 つの側面をカバーするトピックの概要を共有します。

1. 運用および保守チームの構成を確認します。

現在、当社の運用保守（O&M）チームは4つのグループに分かれています。多くの企業と同様に、O&MチームはアプリケーションO&M、システムO&M、O&M開発、監視O&Mに分かれています。もちろん、DBAチームやセキュリティチームもありますが、ここでは割愛します。O&Mチーム全体の人員は現在40名未満です。

私たちのチームの分担は次のとおりです。

• アプリケーション運用・保守：オンラインビジネスのサポートを担当します。各担当者は担当する事業ラインを担当します。主な業務は、オンラインビジネスの安定性確保、開発部門との連携による事業支援、オンラインサービスの管理と継続的な最適化です。

• 運用保守開発：運用保守の作業効率向上を支援し、便利で迅速なツールを開発し、プラットフォームベースで自動化された運用保守を実現します。

• システム運用と保守: オペレーティング システムのカスタマイズと最適化、IDC 管理とマシンの配信、ジャンプ サーバーおよびアカウント情報の管理を担当します。

• 監視と保守: 障害を検出し、関係者に直ちに通知し、簡単な障害をタイムリーに処理し、劣化の解決策を開始する責任を負います。

2. レビューの全体構成

まずはレビューでデータセンターの状況を見てみましょう。

システムは現在、デュアルデータセンター構成で運用されています。データセンターAは主にオンラインサービスを実行し、データセンターBはHadoopクラスター、ログバックアップ、ディザスタリカバリ/ダウングレードアプリケーション（構築中）などのテスト環境とビッグデータ処理ジョブをホストしています。システムは現在、約10,000台の物理マシンと仮想マシンを収容しています。

#p#

多くのインターネット企業と同様に、Dianpingの全体的なアーキテクチャは多層構造のレイヤーモデルを採用しています。それでは、Dianpingの全体的なアーキテクチャを詳しく見ていきましょう。

上の画像は基本的にレビュー プラットフォームの全体的なアーキテクチャを要約したものです。

• ユーザー ブートストラップ レイヤーでは、サードパーティのインテリジェント DNS + CDN が使用されます。

• 負荷分散は、まずレイヤー4ロードバランサとしてF5を使用し、次にレイヤー7ロードバランサとしてDengineを使用します（DengineはTengineをベースにした二次開発です）。その後、Varnishがページキャッシュを処理し、リクエストはWebクライアントにルーティングされ、Webクライアントは内部プロトコルを介してサービス（RPC）を呼び出します。

• イメージストレージには mogileFS 分散ストレージを使用します。

• すべてのサービスには高可用性ソリューションが備わっており、すべてのアプリケーションには少なくとも 2 台のサーバーがあります。

• もちろん、実際のビジネスはもっと複雑です。これは、理解を助けるための単純なレベルの概要にすぎません。

現在、レビューと運用監視は次の 4 つの側面から実施されています。

1. ビジネス レベルの指標には、グループ購入サービスの 1 秒あたりの訪問数、グループ購入バウチャーの 1 秒あたりのクーポン確認数、および 1 分あたりの支払いおよび注文作成数 (cat) が含まれます。

2. アプリケーション レベルでは、エラー数、呼び出しプロセス、平均アクセス時間、最大アクセス時間、95 行など (cat) はすべて各アプリケーションのデータ ポイントです。

3. システム リソース レベル: CPU、メモリ、スワップ、ディスク、負荷、メイン プロセスの存続など (Zabbix)。

4. ネットワーク レベル: パケット損失、ping の有効性、トラフィック、TCP 接続数など (zabbix cat)。

3. 運用保守体制の見直しと導入

Dianping の運用およびプラットフォーム アーキテクチャ チームは、Dianping の全体的な運用および保守システムを構成する多くの実用的なツールを開発しました。

自動化された運用・保守（O&M）は現在、ホットな話題ですが、個人的にはこれはあくまで指針であり、厳格な概念を作り上げたり、盲目的に適用したりする必要はないと考えています。多くの企業で自動化が盛んに行われており、それぞれ独自のアプローチが取られています。しかし、定義に関わらず、O&M担当者は企業内に存在する問題に様々な視点から取り組み、解決していく必要があります。

この点に関しては、私たちも手探りで進んでいます。まずコンポーネントを作成し、次にそれらを統合するというアプローチです。コンポーネントの作成と統合を通じて、徐々に私たちに最適な自動化された運用・保守のフレームワークを形作っていくことができます。

当社の経営理念は次のとおりです。

1. プログラムで実行できるタスクについては、プログラミングとプラットフォーム化を通じて断固として実装する必要があります。

2. 経営によって解決できる問題は、テクノロジーによって解決すべきではありません。

3. 同じ間違いを3回繰り返すべきではありません。

4. すべての失敗は学び、改善する機会です。

5. 誰もが製品志向を持つべきであり、プラットフォーム製品を開発する際には、開発者がセルフサービス型のアプローチを取れるようにする必要があります。

6. 小さな単一の関数を組み合わせて複雑な操作を完了します (タスク分解)。

そこで、私たちは自分たちのアイデアを仕事に取り入れ、多くのツールを作成しました。

まず、運用と保守のツールとシステムの全体的な概要と概要を説明します。

• ビジネス、アプリケーション、ネットワーク、システムといったあらゆる側面を網羅する包括的な監視システムで、あらゆる問題に関する直感的なフィードバックを提供します。アプリケーションレベルごとに異なる監視およびアラームポリシーが実装されています。

• 自動化ツール システム:ツールベースのアプローチは、小さな戦略の組み合わせを使用して大規模なタスクを完了することで、反復的でエラーが発生しやすく面倒なタスクを可能な限り達成するために使用されます。

• 構成および管理システム:複雑な構成管理の場合は、テンプレート定義と標準に従い、できるだけ Web ベースで標準化され、シンプルなものにする必要があります。

• 記録・分析システム：問題やデータを記録・分析し、継続的にシステムを要約、改善、強化します。

#p#

一つずつ紹介していきましょう。

3.1 包括的な監視システム

Zabbixは皆さんよくご存知だと思いますので、ここでは詳しく説明しません。主にcatの監視について紹介します。

• ビジネス監視:

これはCATアプリケーションの監視チャートです。ビジネスの観点から問題を視覚的に特定し、ベースラインと比較することで問題箇所を正確に特定できます。チャートに示されているように、トラフィックは正常であるにもかかわらず、支払いデータが大幅にずれており、バックエンドに問題がある可能性を示唆しています。

これらに加えて、注文の作成、支払い、ホームページの訪問、モバイルの訪問などのビジネスデータもあります。

このチャートはビジネスの観点から監視されます。

これはビジネス視点からの監視ツールでもあります。モバイルアクセス量の推移を示すチャートに加え、レイテンシ、成功率、リンクタイプ、キャリアなどの明確なデータも含まれており、ビジネスを包括的にカバーできます。

• アプリケーション監視:

ビジネス レベルから下に移動すると、アプリケーション レベルになります。

アプリケーションステータスダッシュボードは、ビジネスコンポーネントの現在のステータスを明確に表示します。特定のビジネスが利用できず、その配下の特定のアプリケーションで多数のエラーが発生している場合、そのアプリケーションに問題の原因がある可能性があることを示します。

この監視ダッシュボードには、ビジネスの申請状況が明確に表示され、特定のビジネスやドメイン名が開けない場合に、その原因をすぐに特定できます。

下の画像はアプリケーションエラーダッシュボードです。問題のあるアプリケーションはリアルタイムでリスト表示されます（データは1秒ごとに更新されます）。重大な障害が発生した場合、運用・保守担当者は一目で問題を特定できます。ただし、複数の異なるサービスが同時にエラーを報告している場合は、共通のインフラストラクチャサービスに問題がある可能性があります。

次に、下の画像のこの機能をご覧ください。これはCatの最も強力な機能で、アプリケーション間の通話プロセスを完全に表示できます。何が行われたか、どのようなリクエストが行われたか、どのくらいの時間がかかったか、成功率、トラフィック量など、すべてが一目でわかります。Catは、ビジネスレベルとアプリケーションレベルでほぼ包括的な監視範囲を提供し、ネットワークレベルなどの監視も可能です。つまり、非常に強力なのです。これは、レビューで言及したEagle Eyeシステムでもあります。

#p#

• Logscan ログスキャンツール:

Logscan は、定義した戦略に従ってログコンテンツのスケジュールスキャンを実行できるログスキャンツールです。このツールはコンテンツベースの検出に対応しており、Zabbix および cat と組み合わせることで包括的なカバレッジを実現します。例えば、一部の攻撃リクエストは URL を継続的に通過しますが、これは cat や Zabbix では効果的に捕捉できません。ログスキャンを使用すれば、このような攻撃を容易に検出できます。

3.2 自動化作業システム

まず、レビュープロセスシステムであるワークフローシステムを紹介します。

名前が示すように、ワークフローは、すべてのオンライン変更を標準化されたプロセスに整理することを主な目的としたプロセス システムです。

プログラムが実行できる場合は手動で操作する必要はない、という原則に従います。

このプロセスには、開始、監査、実行、検証といった様々な状態遷移が含まれます。ユーザーは独自の要件変更を開始することができ、運用・保守担当者によるレビュー、実行（ほぼ自動）、検証が行われます。容量拡張、展開、メモリダンプ、IPブロッキングといったプロセスはすべて自動化されています。

当社のオンライン自動スケーリングプロセスを例に挙げると、ユーザーは必要な情報を入力して送信するだけで、運用チームがバックグラウンドで確認を行い、スケーリングは完全に自動化されます。スケーリングが完了すると、メールで通知が送信されます。運用チームは、プロセス全体を通してサーバーにログインして操作する必要はありません。（自動化はそれほど複雑な技術的課題ではなく、小さなタスクを組み合わせ、適切な戦略を立てることで実現できます。）数十台のマシンをスケールアップする場合、運用チームは承認ボタンをクリックするだけで済み、所要時間はわずか数分です。

長年にわたるプロモーションを経て、現在ではDianpingにおける変更の98%以上がワークフロープラットフォームを通じて完了しています。すべての変更は記録されるため、問題が発生した場合の法的根拠が確保され、違反を是正することができます。

さらに、ワークフローシートの利用頻度を分析することで、どの業務が頻繁に行われているのか、自動化できるのか、最適化の余地はあるのかといったデータ分析が可能になります。これこそが、プラットフォーム構築の真の意味、すなわちユーザーセントリックなのです。

プロセスシステムの紹介はこれで終わりです。皆さん、その中核となる概念に注目してください。

#p#

次に、もう 1 つの重要なコア システムであるボタン システムを紹介します。

Buttonは、コード管理、パッケージング、デプロイ、そしてローンチを実現するシステムです。開発者は、コードのアップロード、テストの自動化、パッケージング、プレリリース、カナリアリリース、本番ローンチ、そして問題のロールバックまで、すべてを独立して行うことができます。運用・保守プロセス全体を通して、介入を必要とせず、プラットフォームの完全な自律性を保証します。

Dianping（中国のレビュープラットフォーム）の運用・保守チームは、自動化できない一部の手動設定を除き、ほぼ完全にセルフサービス開発に依存しています。これが自動化の力です！

Go プラットフォーム システムは、バッチ再起動、ダウングレード、切り替え、オンライン/オフライン、ステータス検出などの多くの日常的な操作を含む運用および保守オペレーティング システムです。

このシステムは、運用保守担当者のスキルレベルのばらつきや、ツールの多様な使用状況といった課題に主に対処します。例えば、バッチ再起動操作において、SSHを使用する担当者もいれば、Fabricを使用する担当者もいれば、独自のシェルスクリプトを作成する担当者もいます。この課題を解決するには、プラットフォーム上で操作を定義し、標準化することで、プロセスを統一・標準化します。運用保守担当者が問題に遭遇することは稀であり、問​​題が発生する頻度も低いため、バッチ再起動スクリプトを探すのに時間がかかります。自動化できない機能は、Go言語に大部分が統合されており、基本的にワンクリックで操作できるユーザーフレンドリーな操作となっています。

現在、当社の監視チームは高度な技術スキルを必要とせずに柔軟に業務を遂行できるようになり、すべての操作が記録され、適切な監査と承認が保証されています。

すべてのバックエンド実装は、主にPythonとシェルスクリプトに基づいています。小さなスクリプトグループをタスクに統合することが、私たちの重要な原則の一つです。より複雑なタスクについては、タスクを細分化し、より小さな単機能コンポーネントを組み合わせて複雑な操作を完了します（タスク分解）。自動化へのアプローチも、まずパーツを作成し、次にそれらを組み立てるという、同じロジックに基づいています。

PuppetやGoといったツールが利用可能であるにもかかわらず、特定のジョブの管理は依然として大きな課題です。私たちのアーキテクチャチームは、強力な管理インターフェースを備えた分散cronジョブであるタスクスケジューリングシステムを開発しました。このシステムは完全に自律的な管理を提供し、実行したいジョブと戦略を定義するだけで完了します。ジョブの処理、ステータス更新の記録、監視など、あらゆる処理を自動化することで、完全なセルフサービスを実現します。

これらのシステムはすべて、詳細なデータ統計と分析を備え、ユーザーエクスペリエンスを重視しています。定期的にレビューされ、継続的に改善・最適化されており、真の意味で製品の自動操作を実現しています。その他の自動化システムについては、ここでは詳しく説明しません。

#p#

3.3 構成および管理システム

まずPuppetの管理システムについてご紹介します。Puppetの構文が苦手で、ミスによって生じる問題の深刻さを身をもって体験した方も多いのではないでしょうか。

さらに、複数の人が共同作業を行う場合、テンプレートとファイル名はますます奇妙になり、認識できなくなります。

これらの問題に対処するために、Dianping は主に Puppet 構文を解析し、Web ベースの管理を可能にし、標準化された制約を課す管理ツールを開発しました。

Go システムと同様に、Puppet のモジュールはモジュール セット (メソッド セット) に組み合わせることができ、簡単に識別して柔軟に管理できます。

以下は、当社のオンラインSLB管理システムであるソフトウェアロードバランサ管理ページです。その中核機能は、XMLを使用したNginx構文の解析、Webベースの管理、ユーザーフレンドリーな設定、標準化された設定、偶発的なエラーの防止、バージョン管理、障害のロールバックを実現することです。

レビュー システムは多数あり、基本的に、問題点に遭遇した場合、誰かがそれを解決しようとします。

次に、もう 1 つの強力な構成システムである Lion を紹介し、レビューします。

Lionはアプリケーション構成管理システムです。レビュー対象のアプリケーションで使用されるすべての構成は、ローカルのテキストファイルではなく、キー/バリューペアを使用して別のシステムに保存されます。また、Lionは完全にプラットフォームベースであり、運用・保守担当者がアクセス制御と監査を担当します。開発は完全にセルフサービスです。

その中核は、ZooKeeperの管理メカニズムを利用して、ZooKeeperのディレクトリノードに設定情報を保存します。その後、変更が必要なすべてのアプリケーションマシンは、設定情報の状態を監視します。設定情報が変更されると、各アプリケーションマシンはZooKeeperから通知を受け取り、ZooKeeperから新しい設定情報を取得してシステムに適用します。

Dianping（中国の口コミプラットフォーム）の運用・保守は、はるかに簡単ではないでしょうか？あらゆる操作がツールベースでセルフサービス化され、自動化されています。では、運用・保守担当者は他に何をするべきなのでしょうか？

#p#

3.4 記録・解析システム

これらのシステムは目立たないように見えるかもしれませんが、私たちにとって大きな助けとなっています。いくつかのシステムのデータ記録と分析を通じて、多くの問題点を発見し、潜在的な問題を解決することができました。さらに重要なのは、継続的な改善と集約のプロセスを通じて多くのことを学ぶことができたことです。

これは当社の障害分析システムです。すべての障害が記録され、それぞれの障害が解決された後、ケースごとに詳細な分析と概要が行われます。実際、前述のシステムの多くは、これらの記録から派生しています。

このシステムは不具合記録システムです。不具合ごとに原因と改善策が示され、定期的にレビューされます。

運用と保守は簡単ですか？決して簡単ではありませんが、重点は移行しました。私たちは反復的で面倒な作業を避け、開発チームと緊密に連携して運用品質と継続的な最適化に注力しています。

次に、DianpingのDOMシステム、つまりオペレーション品質管理プラットフォームについて見てみましょう。このプラットフォームは、オンラインサーバーの状態、アプリケーションの応答品質、リソースの使用率、業務上の障害など、さまざまな側面をまとめた包括的なデータ集約プラットフォームです。

前年比、前月比、平均指標などを比較することで、開発チームはプラットフォームベースで競争でき、パフォーマンスの低い運用・保守チームの改善が促進されます。

最後にご紹介したいのは、現在私たちが取り組んでいるかなりハイエンドなプロジェクトであるレーダー システムです。

ご存知の通り、システム数が多いとトラブルシューティングには非常に時間がかかります。多くの同僚が本番環境で同様の問題に遭遇しています。一体何が問題の原因なのか？どの部分に問題があるのか​​？この問題を解決するため、オンラインの問題を分類し、迅速な特定を可能にする戦略レベルのアルゴリズムを実装しました。これにより、デプロイメント時間、リクエスト数の減少、エラー数の増加など、障害間の文脈的な関係性を把握し、どの障害が先に発生し、どの障害が後に発生したのかを把握することが可能になります。もちろん、この機能はまだ開発中です。目標は、問題発生時にレーダーシステムを用いて、その種類と範囲を瞬時に特定できるようにすることです。

上記は、Dianping の運用保守システムを示したものであり、これは当社の Dianping 運用保守理念を体現したものと考えています。

過去数年間、Operations Review の主な目標は、プラットフォームの標準化、効率的な運用と保守、および独立した開発を実現することでした。

以前は、運用チームはrootログインとスクリプトに頼ってコマンドを一括実行していたため、運用効率が悪かったのです。また、CMDBシステム情報の不正確さや導入データの整理の不備といった問題も発生していました。さらに、重大な問題が発生し、運用スタッフが多忙な状況にもかかわらず、根本原因を特定できないという状況にも遭遇しました。

幸いなことに、私たちの努力により、これらの問題は大幅に改善されました。システムデモを通じて、レビュープラットフォームの運用・保守の進歩を実感していただけると思います。

#p#

4. 運用・保守における落とし穴と改善点

運用と保守に関して長年にわたって検討してきたいくつかのケーススタディを共有し、私たちが行ってきた具体的な作業について説明したいと思います。

1. 変更は誰が行ったか分からないまま行われ、復旧不可能な状態でした。また、変更の根拠も不明だったため、重大な障害が発生しました。// 以前は、オンラインPuppetはVimで管理されていました。運用エンジニアのミスにより誤った設定がプッシュされ、1時間にわたり全サービスが利用不能となりました。その後、Puppetの設定変更を標準化し、ツール化し、アクセス制御を実装し、ワークフローシステムを追加することで、同様のインシデント発生の防止に努めました。

2. 問題が発生すると、開発者はコードに問題がないと言い、運用チームは環境に問題がないと言います。誰に連絡すればよいでしょうか？ //その後、DOMとcatシステムを使って詳細な診断を行うツールを開発し、問題箇所の特定を比較的容易にしました。

3. 誤ったコマンドが実行されたため、全面的なオーバーホールが発生し、サービスが利用できなくなりました。// Goシステムを使用して日々の運用を効率化し、ツールを作成することで、メンテナンスタスクの90%を自動化プロセスとGoプラットフォームで完了できるようになりました。これにより、障害率が大幅に低下し、その後、権限が取り消されます。

4. 問題が発生しましたが、さまざまなシステムを検索しても、問題をすぐに特定できず、根本原因を見つけることができません。 //コメント: 現在、過去の問題を確認し、障害の種類を分類し、戦略とアルゴリズムを使用してレーダー システムをスキャンし、問題のあるセグメントをすばやく優先順位付けして表示できるようにするレーダー システムを開発しています。

5. 運用保守（O&M）スタッフは常に多忙であるにもかかわらず、成果が見えず、開発者から批判され続けています。// この2年間で状況は一変しました。現在、ほとんどのシステムがセルフサービス開発を実現したため、O&Mは開発を大きくリードしています。O&Mスタッフはプラットフォームの継続的な改善と業務運営の品質向上に集中できるようになりました。DOMシステムはカスタマイズ可能で、O&Mスタッフは各事業のコアパフォーマンス指標レポートを毎日上級管理職に送信しています。開発部門は、サービス品質の問題やレスポンスの遅さを即座に修正します。（もちろん、これには上級管理職のサポートが不可欠です。）

5. 今後の注力分野と方向性

レビューでは、人気の PaaS テクノロジーなどの最先端のトピックも取り上げます。

PaaSとクラウドコンピューティングは、Dockerテクノロジーと同様に非常に普及しています。Dianpingも遅れをとることはできません。現在、Dianpingは数千のDockerインスタンスをオンラインサービスで運用しています。

上の画像に表示されている Java インスタンスはすべて、Docker インスタンスを実行しています。

現在、Dockerは10秒以内に迅速にデプロイでき、ユーザーの要求に応答できます。インスタンスの移行は30秒以内にシームレスに完了します。個人的な意見としては、Dockerの技術は基盤レイヤーではなく、上位レベルの管理システムの構築にあると考えています。下位レイヤーにおける継続的な最適化とパフォーマンス向上は重要ですが、戦略とスケジューリングレイヤーはさらに重要です。迅速なデプロイ、移行、リカバリ、デグレード、そしてスケーリングを実現することは、依然として大きな課題です。

このレビューは過去2年間で大きく進展しましたが、まだ道のりは長いです。今後は、複数のシステムの有機的な統合、新技術の試行と開発に重点を置き、インテリジェント戦略のレベルにさらに注目していく予定です。

結論

最後に、ご来場いただいた皆様、そしてDianpingの運用・プラットフォームアーキテクチャチームのすべての同僚の皆様に感謝申し上げます。皆様のおかげで、Dianpingの運用はここまで発展しました。共に、運用・保守システムの新時代を築き上げていきましょう。

レビューされたシステムの多くは、皆様に初めて公開されるものなので、その設計コンセプトや根底にあるアイデアをぜひご覧ください。

共に幸せに成長する方法

これは新しい時代です！誰もが自分の意見を持ち、尊重されるべきであり、尊重される機会を持っています。

「効率的な運用と保守」WeChatグループは2015年4月末に設立され、中国を代表するハイエンド運用保守（O&M）サークルへと成長しました。中心メンバーは、大手インターネット企業をはじめ、モバイル通信、銀聯（ユニオンペイ）、農業など、様々な業界の出身者など、幅広いバックグラウンドを持つメンバーで構成されています。「効率的な運用と保守」WeChat公式アカウントはフォローする価値があります。このアカウントは、毎日約1件の記事（90%がオリジナル）を投稿し、「効率的な運用と保守」グループで行われた優れた議論をまとめています。また、「効率的な運用と保守」は、InfoQコラム「効率的な運用と保守のベストプラクティス」とO&M 2.0の公式WeChatアカウントでもあります。

さあ、友人たちよ、この壮大なイベントに参加しましょう。

重要な注意: この記事を転載する場合は、この行と下の QR コードを含む記事全体を転載する必要があります。