＃＃＃導入＃＃＃
| 運用とメンテナンスの自動化は私たちが切望しているものですが、やみくもに自動化機能を強調すると、自動化の実装に影響を与える重要な要素を無視することになります。それは、日夜運用と保守に追われる人々が好む、または憎むビジネス構造です。
|
ビジネスアーキテクチャは運用保守の効率と品質を決める重要な要素の一つですので、どのようなアーキテクチャ設計が運用保守に優しいのかについてお話したいと思います。 Tencent で長年にわたって遭遇したビジネス アーキテクチャと、運用および保守計画を行う際のビジネスの非機能仕様についての考え方を組み合わせると、 運用および保守指向のアーキテクチャ設計を 6 つの主要な設計ポイントに分けることができます。
ポイント 1: アーキテクチャの独立性
あらゆるアーキテクチャは、特定のビジネス要件を満たすために作成されますが、アーキテクチャ管理の運用保守という非機能要件も考慮しながら、ビジネス要件を満たせる場合に限ります。したがって、そのようなアーキテクチャは運用と保守に優しいと考える理由が得られます。
運用と保守の観点から見ると、要求されたアーキテクチャには 独立した展開、独立したテスト、コンポーネント化、および 技術的分離という 4 つの側面が含まれます。
独立した展開
は、運用と保守を容易にする管理要件に応じて展開、アップグレード、拡張などが可能なソース コードを指し、地理的な分布は構成によって区別できます。サービス間の相互呼び出しはインターフェイス リクエストを通じて実装され、展開の独立性は運用と保守の独立性の前提条件でもあります。
独立したテスト
運用と保守は、便利なテスト ケースやツールを通じて、ビジネス アーキテクチャやサービスの可用性を検証できます。この機能を備えたビジネス アーキテクチャまたはサービスにより、リリースや変更のたびに開発者やテスターの参加を必要とせずに、運用と保守を独立してオンラインに移行できるようになります。
コンポーネントの仕様
は、同じ企業内で関連テクノロジーに対する適切なフレームワーク サポートがあることを指します。これにより、異なる開発チームが異なるテクノロジー スタックやコンポーネントを使用して、企業の内部技術アーキテクチャが制御不能になるのを防ぎます。
このアプローチにより、運用および保守オブジェクトの無秩序な増加を制限することができ、運用および保守が常に本番環境の制御を維持できるようになります。同時に、運用とメンテナンスがより多くのエネルギー投資を維持し、標準コンポーネントを中心により効率的で高品質な建設作業を実行できるようになります。
技術的なデカップリング
は、サービス間の相互依存性を減らすことを指します。また、構成ファイルに対するコードの依存性を減らすことも含まれます。これは、マイクロサービスを実現し、独立したデプロイメント、独立したテスト、およびコンポーネント化を実現するための基礎でもあります。
ポイント 2: 導入しやすい
DevOps には、継続的デリバリの技術的実践について多くのスペースがあり、開発、テスト、運用とメンテナンスのすべての技術的なリンクをエンドツーエンドでオープンにして、迅速な展開と価値の提供という目標を達成することを望んでいます。 導入は日常の運用および保守作業の非常に重要な部分であることがわかります。これは繰り返しの多い計画的なタスクであり、効率を向上させる必要があります。
効率的で信頼性の高い導入機能を実現するには、全体的な計画を立てて、導入フェーズと運用フェーズで包括的な運用と保守の制御を確保する必要があります。導入のしやすさに関連するコンテンツには 5 つの側面があります:
CMDB 構成 #各展開の運用前に、運用と保守は、全体的なワークロードと潜在的なリスクをよりよく理解して評価するために、アプリケーション、アーキテクチャ、ビジネスの関係を明確に理解する必要があります。
Zhiyun自動運用保守プラットフォームでは、業務関係、クラスタ管理、稼働状況、重要度、アーキテクチャ層などの構成情報を運用保守管理オブジェクトとしてCMDB構成管理データベースで管理することに慣れています。この管理方法の利点は明らかであり、運用および保守オブジェクトの構成情報を一元的に保管することで、運用および保守操作、監視および警報などの自動化機能の構築に大量の構成データのサポートと意思決定の支援が提供されます。未来。
環境構成
運用と保守の標準化が低い企業では、導入と配信の効率性を妨げる原罪の 1 つは環境構成であり、これはコンテナ化テクノロジが主に解決したい運用と保守の問題点の 1 つでもあります。 Tencent の運用保守業務では、開発、テスト、運用という 3 つの主要な環境の標準化された管理が、環境に関連するリソースの収集と運用保守業務を列挙して管理し、自動初期化ツールと組み合わせて実現されます。標準的な環境管理を実現します。
依存関係の管理
アプリケーション ソフトウェアのライブラリや動作環境などへの依存関係の管理を解決します。 Zhiyun の実践的な経験では、パッケージ管理を使用して、パッケージ全体と実行前および実行後スクリプトを通じて依存ライブラリ ファイルまたは環境を構成し、さまざまな環境にアプリケーション ソフトウェアを展開する問題を解決します。業界には軽量のコンテナに梱包された配送方法もあり、これも良い選択肢です。
導入方法
継続的デリバリーの原則では、信頼性が高く再現性のあるデリバリー パイプラインを構築する必要性が述べられており、アプリケーション ソフトウェアのデプロイメント運用もこの目標に従って強力に計画されます。 Docker の Build、Ship、Run など、Zhiyun の構成説明、標準化されたプロセスのワンクリック デプロイメントなど、業界には参考になる事例がたくさんあります。
セルフテストの公開
セルフテストの公開は 2 つの部分で構成されます:
- アプリケーションの軽量テスト;
- 公開/変更されたコンテンツの校正。
これら 2 つの機能を構築して、さまざまな運用および保守シナリオのニーズに対応します。たとえば、増分リリース中に、公開されたコンテンツの校正機能を使用すると、運用および保守担当者は変更ファイル md5 を迅速に取得したり、関連するファイルを確認したりできます。プロセスとポート構成情報がチェックおよび比較され、リリースされた各変更の信頼性が保証されます。
同様に、軽量テストは、リリース時のサービス可用性テストのニーズを満たします。このステップでは、サービスの接続を検出し、いくつかのバックボーン テスト ケースを実行できます。
グレースケールはオンラインです
「日常の運用と保守のための 36 の戦略」には次の文があります。 元に戻せない削除または変更操作の場合は、遅延させるかゆっくりと実行するようにしてください。これがグレースケールの考え方であり、オンラインでのグレースケールであっても、ユーザーの緯度、時間、サーバーなどから、オンライン運用のリスクを可能な限り軽減したいと考えており、その能力をサポートするビジネスアーキテクチャです。グレースケール リリースにより、アプリケーション展開プロセスのリスクが軽減され、運用とメンテナンスがより容易になります。
ポイント3：操作性
運用保守を考える上で最も理想的なマイクロサービスアーキテクチャは、操作性と保守性が高いものでなければなりません。 運用や保守が不可能なアプリケーションやアーキテクチャは、運用や保守チームに問題を引き起こすだけでなく、彼らのキャリア開発に深刻な悪影響を及ぼします。なぜなら、運用や保守が不可能なアーキテクチャを保守するのは単なる時間の無駄だからです。 . 運用保守員の命の無駄です。
運用性と保守性は、運用仕様と管理仕様から以下の7点に集約されます。
構成管理
マイクロサービス アーキテクチャ管理では、独立したデプロイメントを容易にするために、アプリケーション バイナリ ファイルと構成管理を分離することを提案します。
分離されたアプリケーション構成には
3 つの管理方法がある :
ファイルモード;
- 設定項目モード;
- 分散構成センター モード。
-
紙面の都合上、上記 3 つの方法の長所と短所については説明しません。企業ごとに最適な構成管理方法を選択できますが、重要なのは、各企業が一貫したソリューションを使用することを要求し、運用保守が目的の構成管理用ツールとシステムを構築できるようにすることです。
バージョン管理
DevOps 継続的デリバリーの 8 つの原則の 1 つは、「すべてをバージョン管理に置く」です。運用や保守の対象を適切に管理するには、それを明確に記述できなければなりません。
ソースコード管理の要件と同様に、運用および保守でも、パッケージ、構成、スクリプトなどの日常的な運用オブジェクトのスクリプト化された管理を実行する必要があります。これにより、運用および保守システムが自動化された運用を完了すると、操作対象のオブジェクトとバージョンを正確に選択できます。
標準操作
日々の運用やメンテナンスでは、非常に反復的なタスクが多数あります。リーン思考の観点から見ると、ここには学習コスト、無駄な操作、スクリプト/ツールの繰り返し構築、人肉処刑などの危険性が待っています。
ファイル転送、リモート実行、アプリケーションの起動・停止など、運用・保守の運用仕様を企業内で統一できれば 運用の標準化・一元化・ワンクリック化が実現します 、運用・保守効率と品質が大幅に向上します。
プロセス管理
アプリケーションのインストールパス、ディレクトリ構造、標準化されたプロセス名、標準化されたポート番号、起動・停止方法、監視計画などがプロセス管理の範疇に含まれます。 プロセス管理の全体的な計画を適切に行うと、運用と保守の自動化の程度が大幅に向上し、計画外のタスクの発生を減らすことができます。
スペース管理
ディスク領域の使用状況を適切に管理することは、ビジネス データを規則的に保管することであり、計画外のタスクの発生を減らす効果的な手段でもあります。
事前の計画が必要です: バックアップ戦略、ストレージ計画、容量警告、クリーンアップ戦略など。これらのタスクを効果的なツールで補完して、ペストの運用とメンテナンスが長くなります。
ログ管理
ログ仕様の推進と実装には、研究開発との緊密な協力が必要です。実際に得た経験に基づいて、運用と保守のための理想的なログ仕様には次の要件が含まれる必要があります。
ビジネスデータとログの分離
- ログとビジネス ロジックの分離
- 統一されたログ形式
- 戻りコードとコメントは明確です
- 業務指標が取得可能(リクエスト量/成功率/遅延)
- 主要なイベントを定義する
- 出力レベル
- 管理計画 (保存期間、圧縮バックアップなど)
-
上記の条件に特化したログ仕様を実装すると、開発、運用保守、ビジネスの監視・分析能力が向上します。
集中管理
運用保守の作業は本質的に、リリース変更、監視と分析、障害対応、プロジェクトサポート、マルチクラウド管理など、さまざまな部分に分割されやすいものです。 私たちはワンストップを追求します。あらゆる業務情報の接続と経験の継承を可能にする運用保守管理プラットフォームにより、情報の孤島や人手による情報伝達による運用リスクを排除し、運用保守管理全体の効率と品質を向上させます。
ポイント 4: フォールト トレランスとディザスタ トレランス
Tencent の技術運用 (運用と保守) における 4 つの主要な責任: 品質、効率、コスト、セキュリティ。品質は主な保証です。アーキテクチャの観点から、運用と保守の観点から見た理想的な高可用性アーキテクチャ設計には、次の点が含まれている必要があります。
負荷分散
ソフトウェアまたはハードウェアのバランスの取れたソリューションであっても、運用と保守の観点から、私たちはビジネス アーキテクチャがステートレスになり、ルーティングとアドレス指定がインテリジェントになり、クラスターのフォールト トレランスが自動的に実現されることを常に望んでいます。
Tencent の長年にわたるルーティング ソフトウェアの実践において、ソフトウェアの負荷分散ソリューションは広く使用され、ビジネス アーキテクチャにおける高可用性の実現に大きく貢献してきました。
スケジュール
モバイル インターネットが普及した時代において、スケジュール管理は災害復旧や耐障害性を実現するための非常に重要な運用保守方法です。ビジネスですぐに解決できない障害が発生した場合、ユーザーまたはサービスを異常な領域から移動することは、大量運用の実践において実証済みの手法であり、Tencent QQ と WeChat の中核的な運用および保守機能の 1 つでもあり、プラットフォームのビジネス品質。
このアーキテクチャは、ドメイン名、VIP、アクセスゲートウェイなどのテクノロジーと組み合わせることで、スケジューリング機能をサポートし、運用保守管理方法を強化し、さまざまな障害シナリオにより冷静に対応する機能を備えています。 異地多活#異地多活是資料高可用的訴求，是可調度性的前提。針對不同的業務場景，技術實現的手段不限。
騰訊社交的實踐可以參考周小軍老師的文章「2億QQ用戶大調度背後的架構設計和高效運作」。
主從切換#在資料庫的高可用方案中，主從切換是最常見的容災容錯方案。透過在業務邏輯中實現讀寫分離，再結合智慧路由選擇實現無人職守的主從切換自動化，無疑是架構設計對DBA最好的禮物。
柔性可用#「先扛住再優化」是騰訊海量營運思想之一，也為我們在做業務架構的高可用設計點明了方向。
如何在業務量突增的情況下，最大程度的保障業務可用？是做架構規劃和設計時不可迴避的問題。巧妙的設定柔性開關，或是在架構中內建自動拒絕超額請求的邏輯，能夠在關鍵時刻保證後端服務不會雪崩，確保業務架構的高可用。
要點五：品質監控
保障和提升業務品質是維運努力追逐的目標，而監控能力是我們實現目標的重要技術手段。 運維希望架構為品質監控提供便利性和資料支持，要求實現以下幾點：
# 指標度量#每個架構都必須能被指標測量，同時，我們希望的是最好只有唯一的指標測量。對於業務日趨完善的立體化監控，監控指標的數量隨之會倍增。因此，架構的指標測量，我們希望的是最好只有唯一的指標度量。
基礎監控#指的是網路、專線、主機、系統等低層次的指標能力，這類監控點大多屬於非侵入式，很容易實現資料的擷取。
在自動化維運能力健全的企業，基礎監控所產生的警報資料絕大部分會被收斂掉。同時，這部分監控資料將為高階的業務監控提供資料支撐和決策依據，或是包裝成更貼近上層應用場景的業務監控資料使用，如容量、多維指標等。
元件監控#騰訊習慣把開發框架、路由服務、中介軟體等都統稱為元件，這類監控介於基礎監控和業務監控之間，運維常寄望在元件中內嵌監控邏輯，透過元件的推廣，讓組件監控的覆蓋度提高，取得數據的成本屬中等。如利用路由組件的監控，維運可以獲得每個路由服務的請求量、延遲等狀態和品質指標。
業務監控#業務監控的實現方法分主動和被動的監控，即可侵入式實現，又能以旁路的方式達到目的。這類監控方案要求開發的配合，與編碼和架構相關。
通常業務監控的指標都能歸納為請求量、成功率、延遲3種指標。實作手段很多，有日誌監控、流資料監控、波測等等，業務監控屬於高層次的監控，往往能直接回饋業務問題，但倘若要深入分析出問題的根源，就必須結合必要的運維監控管理規範，如返回碼定義、日誌協定等。需要業務架構在設計時，前置考慮到維運監控管理的訴求，全域規劃好的範疇。
全連結監控#基礎、元件、業務的監控手段更多的是聚焦於點的監控，在分散式架構的業務場景中，要做好監控，我們必須要考慮到服務請求鏈路的監控。
基於唯一的交易ID或RPC的呼叫關係，透過技術手段還原呼叫關係鏈，再透過模型或事件觸發監控告警，來回饋服務連結的狀態和品質。此監控手段屬於監控的高階應用，同樣需要業務架構規劃時做好前置規劃與程式碼埋點。 。
品質考核#任何監控能力的推進，品質的最佳化，都需要有管理的閉環，考核是一個不錯的手段，從監控覆蓋率、指標全面性、事件管理機製到報表考核打分，運維和開發可以攜手打造一個持續回饋的品質管理閉環，讓業務架構能夠不斷進化提升。
要點六：效能成本
在騰訊，所有的技術營運人員都肩負著一個重要的職能，就是要確保業務營運成本的合理。 為此，我們必須對應用吞吐性能、業務容量規劃和營運成本都要有相應的管理辦法。
# 吞吐性能#DevOps持續交付方法論中，在測試階段進行的非功能需求測試，其中很重要一點便是對架構吞吐性能的壓測，並以此確保應用上線後業務容量的健康。
在騰訊的實踐中，不僅限於測試階段會做效能壓測，我們會結合路由元件的功能，對業務模組、業務SET進行真實請求的壓測，以此建立業務容量模型的基準。也從側面提供資料論證該業務架構的吞吐性能是否達到成本考核的要求，利用不同業務間性能數據的對比，來推動架構性能的不斷提高。
容量規劃#英文capacity一詞可以翻譯成：應用效能、服務容量、業務總請求量，運維的容量規劃是指在應用效能達標的前提下，基於業務總請求量的合理的服務容量規劃。
營運成本#減少營運成本，是為公司減少現金流的投入，對企業的價值絲毫不弱於品質與效率的提升。
騰訊以社群、UGC、雲端運算、遊戲、影片等富媒體業務為主，每年消耗在頻寬、裝置等營運成本的金額十分龐大。維運想要優化營運成本，常常會牽涉到產品功能和業務架構的最佳化。因此，維運理想的業務架構設計需要有足夠的成本意識，
小結
本文純屬個人以維運視角整理的對微服務架構設計的一些愚見，要實現運維價值最大化，要確保業務品質、效率、成本的全面提高，業務架構這塊硬骨頭是不得不啃的。
維運人需要有架構意識，能站在不同角度對業務架構提出建議或需求，這也是DevOps 精神所提倡的，開發和維運聯手，持續優化出最好的業務架構。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
