SRE における自動進化の適用

＃＃＃導入＃＃＃ SRE は Site Reliability Engineering の略称で、Google の社内製品テクニカル サポート プロセスから発展した新しい運用および保守モデルであり、新しい役職の責任範囲を定義します。従来の運用および保守モデルとは異なり、SRE は自動化されたシステムを重視し、ソフトウェア エンジニアリング手法を通じて、反復的な手動操作に代わるいくつかのシナリオ ベースの自動運用および保守ツールの開発を提唱しています。このチャットでは、海外の SRE 実践事例を通じて SRE 自動化の進化を紹介します。

コンテンツには次のものが含まれます:
SRE にとっての自動化システムの価値;
自動化システムの進化;
海外インターネット企業の SRE 自動化適用事例;
国内運用保守分野における自動化実践。

1.SRE とは何ですか?

SREとはSite Reliability Engineeringの略で、海外のインターネット企業発祥の言葉、または新しく定義された位置づけです。従来のシステム管理者モデルの時代には、この役割を運用保守と呼んでいましたが、海外ではオペレーションと呼ばれていました。

Google SRE 担当副社長は Ben Treynor です。2003 年に入社したときの最初の仕事は、7 人からなる「運用運用および保守チーム」を結成することでした。しかし、Google マシンの増加のスピードを考慮すると、従来の運用および保守モデルでは信頼性の高い運用および保守の要件をすぐに満たすことができないことがすぐにわかりました。彼自身も上級ソフトウェア開発者であるため、R&D チームと同様に運用保守チームを編成しました。当社では、開発能力とシステム管理の知識を備えた研究開発エンジニアを多数採用していますが、最も重要なのは、繰り返し作業を嫌うことです。彼らは、いくつかのベスト プラクティス、方法、プロセス、メソッドをコードに固め、この方法を使用して規模の拡大と複雑さの増加に対処します。

2. SRE にとっての自動化システムの価値

典型的な SRE 活動は、ソフトウェア エンジニアリング、システム エンジニアリング、些細な事項、およびプロセス負荷の 4 つの部分に分かれています。その中には、日常の運用保守サービスに直接関係する種類の作業があることがわかりますが、これは SRE では非効率な作業として定義されており、Google は今でもそれを説明するために特別な単語「Toil」を使用しています。

トリビアは、運用および保守サービスにおける手動で反復的な戦術的な作業です。その成長はサービスの成長と直線的です。この部分の作業は自動化できます。 Google は、SRE が自分の時間の少なくとも 50% をソフトウェア エンジニアリング プロジェクトに費やすべきであることを公的に提案しています。管理しなければ、些細な事柄がますます多くなり、すぐに SRE 担当者の時間の大部分を占めてしまうからです。些細なことを減らしてサービス規模を拡大する仕事がSREにおけるE（エンジニアリング）です。

このビデオから、SRE にとって自動化の価値は主にパフォーマンスと効率という 2 つの側面からもたらされることがわかります。自動化というと、まず効率の向上を思い浮かべる人が多いと思いますが、実際にSRE担当者は、単に効率を向上させることよりも、システムのパフォーマンスと速度や柔軟性のバランスを重視します。自動化は、運用における手動実行による不整合を排除し、「明確な範囲と既知の手順による一貫した手順の実行」を保証することでシステムのパフォーマンスを保証し、これが自動化の主な価値です。

自動化システムは、スケーラブルで広く適用可能なプラットフォームを提供できます。このプラットフォームは問題を一元管理し、大規模なシステム エラーを処理し、人間よりも継続的かつ頻繁にタスクを実行できます。また、プラットフォームは独自のパフォーマンス指標を公開できるため、以前のプロセスでは気づきにくい詳細を発見するのにも役立ちます。もちろん、プラットフォーム化の基礎は正しい設計と実装にあります。自動化によって効率が向上することを理解しやすくなります。私たちは、自動化されたプログラムの作成に費やした労力と時間と、手動作業をキャンセルすることで節約された部分を比較して分析することがよくありますが、自動化が実装されると、特定の操作が特定のオペレーターから切り離されることを理解する必要があります。測定すると、自動化によって節約された時間と労力はすべてのユーザーに発生するはずです。

Google データセンター クラスタのオンライン プロセスを担当する SRE である Joseph Bironas は、かつて次のように述べています。「自動化できないプロセスやソリューションを作り続ければ、システム メンテナンスを行う人員が引き続き必要になります。 「人を雇いましょう。この仕事をするのは、機械に人間の血、汗、涙を与えるようなものです。特殊効果はありませんが、怒っているシステム管理者でいっぱいのマトリックスの世界のようなものです。」

3. 自動化の進化 Google SRE の自動化プロセスは上記の段階を経ています。最初の段階は、手動操作に完全に依存する非自動化段階であり、その後、外部で保守されるシステム固有の自動化スクリプトを使用して動作します。特定のシステムの自動化は、徐々に一般的なシステムの自動化に進化し、その後、外部で保守される自動化システムが内部で保守される自動化に置き換えられます。自動化システムは最終的に、運用および保守プラットフォームに組み込まれ、手動によるトリガーを必要としない自動化システムに進化しました。

4. 外資系インターネット企業のSRE自動化活用事例 Google のリソース管理システム Borg は、Google SRE で長年使用されている代表的な自動アプリケーション リリース システムです。なぜリソース管理がそれほど重要なのでしょうか? 規模が大きすぎるため、運用コストが進化の唯一の障害になります。技術的に言えば、統合リソース管理システムの実装は非常に難しく、インフラストラクチャの品質によってこのシステムの機能が決まります。特に分散環境では、さまざまなビジネス シナリオにおける物理サーバーの要件はまったく同じではありません。 Google の Borg が統合リソース管理を実現するための前提条件は、GoogleFS、BigTable、Chubby、GSLB などのコア テクノロジーのサポートです。SRE はこのシステムのユーザーであり、常にフィードバックを提供し、システムの信頼性を高めるために Borg システムの使用を改善します。要件、今のところ、Borg は依然として Google 内部で使用されているアプリケーション公開システムです。

まず第一に、Borg システムは完全に階層化されたシステム アーキテクチャです。最も基本的なファイル システムから最上位の負荷オフロードに至るまで、テクノロジー スタックの各層は Google 内で独自のものであり、その利点は、経験を蓄積して再利用できることです。国内企業のシステムアーキテクチャも開発過程で階層的な組織構造を経ており、人的要素は別として、複数のシステムを組み合わせて多くの階層が構築されています。表面的にはコストを削減していますが、実際には人件費の維持コストが増加しています。この時点では、外国のシステムの進歩は横に置いておいても構いませんが、テクノロジーを選択する際に何をすべきでしょうか。経験から言えば、ピア間で共有される複数のオープンソース システムで構成される 1 層システムは、短期的な効果が明らかな近道な方法です。企業のビジネスが急速に発展すると、あらゆるリファクタリングは、状況を覆して最初からやり直すための壊滅的なツールとなります。大小を問わずさまざまなエンタープライズ システムに携わった経験から、私はこの変化のダイナミクスを深く理解しています。 SRE では、ツールを変更するという考えは、古いオープンソース ツールを新しいオープンソース ツールに置き換えることではありませんが、信頼性要件はツールの選択の数を簡素化し、これに基づいて自分たちのニーズを真に考慮する必要があります。自社開発の自動化システムへの道。

第二に、Borg システムのインフラストラクチャ テクノロジーは十分に進んでいますが、SRE は少し冗長ですか?明らかに、テクノロジーの進歩が SRE 手法に取って代わることはできません。現在、業界で最も人気のある DevOps の概念には、コストや信頼性についての詳しい説明は含まれておらず、自動化や生産性の向上などのさまざまな実践に重点が置かれています。これらの実践では、ビジネス シナリオの持続可能な発展という中核的な問題、つまりビジネスの信頼性とコスト管理の間のチェック アンド バランスを解決することはできません。 SRE手法は、最小限のコストで最大限のビジネス上の利益を得るという手法です。そのため、SRE職ではコードが書けるシステム運用保守エンジニアを募集しますが、運用保守だけをやっていると純粋な開発者は絶対に確保できません。したがって、私たちは認知的自由度を高め、現在の企業内部の業務システムをソフトウェア工学の観点から解決する必要があります。著者の個人的な経験から言えば、当社はテストシステム、プロジェクト管理システム、プロセス制御システム、リリースシステムなどの製品を開発するテクノロジー企業です。会社の規模に関係なく、必ず必要になります。 SRE ドライバーがなければ、ギャップを埋めるためにツールを選択することになります。ただし、システムは相互に関連していないため、内部でこの問題の反復を実際に推進できる人は誰もいません。最後に、この問題を運用保守や開発だけで解決してしまうと、完全には解決できないのが現状です。

第三に、SRE は外国のインターネット企業ではどこでも見られますが、中国ではそのような立場やアイデアの普及が非常に少ないのですが、これは文化の違いによるものでしょうか?国内の運営・保守システムは進化し続ける過程において、その開発速度は現在の諸外国の認知レベルに比べて明らかに遅いと筆者は考えている。しかし、タオバオの台頭により、アリババの技術サポート部門は実際に国内 SRE の最良の検証となっています。 SRE の利点は非常に明白ですが、中小企業に SRE を宣伝するのは非常に困難です。最大の問題は、外国の技術サービスプロバイダーのシステムが非常に健全であることであり、中小企業が何らかの SRE 変革を行いたい場合、多数の技術サービスプロバイダーのソリューションを入手できるということです。そして企業は、そのような技術の事前研究プロセスにコストの一部を費やすことに積極的です。国内企業は成熟した技術を購入することを期待しており、インフラへのエネルギー投資には消極的です。コスト管理も人件費を考慮した上で行われており、テクノロジープロバイダーに余裕を持たせることは困難です。このような苦境においては、クラウドコンピューティングビジネスの発展が潤滑油の役割を果たすことができる。言い換えれば、シェアード・テクノロジー・エコノミーは、中国で SRE を導入するための手段となる可能性があります。例えば、筆者が取り組んでいるShuren Cloudは、SREの概念を実現した軽量アプリケーション管理プラットフォームであり、企業と連携することで企業が求めるプラットフォーム構築を完結させます。この協力プロセスでは、進化したシステムが付加価値として機能し、Shuren Cloud Platform によって他の企業に推進され、Win-Win の関係を実現します。結果から判断すると、企業は SRE 実践の成果を上げ、テクニカル サービス プロバイダーは SRE を実践する機会を獲得しました。

第 4 に、SRE はツールをうまく活用します。問題解決から、問題の詳細な分析、そして問題解決のためのモデルとチェックリストの提供への、問題解決方法の変化。たとえば、Linux システムのパフォーマンスを解決するときに Netflix の SRE から SRE に提供されるリストは次のとおりです。

5. 国内運用保守分野における自動化の実践 著者は、国内の運用保守分野における開発の急速な反復に限定して、ブレークスルー ポイントとして最も懸念される 3 つの領域から自動化実践の現状を分析します。

1. 監視アラーム

家庭用の監視および警報ツールは数多くありますが、実装できる一般的なソリューションはほとんどありません。従来の企業で最も一般的に使用されているのは Zabbix ですが、これに加えて、中国の Xiaomi が開発したオープンソースのインターネットエンタープライズレベルの監視ツールである Open-Falcon もオプションです。しかし、どちらのシナリオでも、避けられない非常に直接的な問題があります。それは、最短経路を使用して問題を分析し、ビジネス シナリオにおける実際の問題を解決する方法です。監視の観点から見ると、システム レベル、ビジネス レベル、サービス レベルという複数の側面があります。 SRE の観点から問題に対処する場合、先験的な経験に基づいたさまざまなシステムの遅れに基づいて計画を立てるのではなく、キャパシティ プランニングが最初のステップとなります。したがって、最初からツールは最も難しい問題ではありませんでした。 Zabbix を例にとると、監視できるディメンションは、システムの健全性、データベースの QPS、Redis のメモリです。しかし、Web サイトの速度が低下した場合、監視の観点からは何もできません。問題を特定して解決するには、フルリンク分析が必要です。 DevOps の経験に従っている場合、このような質問はしにくいですが、問題が発生したときに、サーバーを自動的に切り替えたり、容量を自動的に拡張して問題を解決する方法について尋ねます。 DevOps シナリオではコスト管理は制御できません。管理者は予算コストを強制することしかできず、上流も下流も事業運営にかかるコストを完全には理解できません。
2. ログ監視

国内のログ監視では、ELK (Elasticsearch、Logstash、Kibana) テクノロジー スタックが広範囲に使用されています。このテクノロジー スタックは非常に人気があり、企業内の多数の内部ログ問題も解決しています。しかし、実際のシナリオでは、ビジネス ログの管理は依然として非常に面倒です。 1 つはリアルタイム ログのクエリで、2 つ目は履歴ログの集約です。ログ クエリを効果的に使用するにはどうすればよいですか? Qunar の運用および保守チームは、Apache Mesos 上の社内部門にオンデマンド ELK サービスを提供する方法を共有し、開発者がいつでも自分のビジネス ログをクエリし、分析できるようにしました。 。クエリが完了すると、ELK サービス インスタンスは自動的に破棄されます。著者は、この革新的なアプローチは実際には SRE 思考の実践であると信じています。
3. 継続的統合およびリリース システム

国内の運用と保守に最もよく使用されるツールは、Jenkins を使用して継続的統合とリリースを完了することです。しかし、Jenkins を使用できる限り、詳細な練習はやめてしまうことがよくあります。 SRE の観点から、継続的インテグレーションのプロセス中にテスト システムが接続されるため、まず継続的インテグレーションのビジネス上の課題を分析します。したがって、著者は、継続的インテグレーションの目的は、製品の品質を継続的に向上させることであると考えています。この中心的な目標を念頭に置いて、私たちがコントロールするのは、Jenkins ジョブをどのように管理するかだけではなく、テストの効率を向上させ、統合時間を短縮できるかどうかです。目標リストを確立し、それを SRE 改善プロセスに組み込むことで、確実に異なる結果が得られます。継続的なパブリッシングは別のトピックですが、実際問題は、ユーザーがパブリッシングを完全に理解していないことです。リリースには、グレースケール リリース、テスト リリース、ローリング リリース、ロールバック リリース、その他のシナリオが含まれます。そして、すべてのシナリオは元に戻せるものでなければなりません。この問題を解決するにはどうすればよいですか? Jenkins だけではこの問題を解決できません。この問題を満たすには、一連の軽量アプリケーション管理プラットフォームの支援などの拡張ツールが必要です。

6. 概要

業界の発展の歴史から判断すると、テクノロジーの標準化は避けられない進化のプロセスであり、運用と保守の自動化は実際には標準化の現れです。 SRE を始める最初のステップから、仕事の責任を整理して整理し、解決する必要がある問題をチェックリストに文書化する必要があります。ビジネスへの迅速な導入を促進します。次のステップは、これらのビジネス指標とシナリオを視覚化して、企業が運用コストを削減し、サービス システムの目標を定量化できるようにすることです。有能な企業の場合、開発プロセス中にさまざまなリソースのインターフェイスが統一されますが、このプロセスは非常に長くなります。著者の経験から、小さなステップで繰り返し、実際の結果に応じて慎重に実装する必要があります。なぜなら、コストに関係なくプラットフォーム化することは単なる輝かしい政治的成果であり、コスト問題を効果的に解決するものではないからです。自動化の最高の形式は間違いなくインテリジェント システムですが、著者の視点から見ると、おそらく誰もが SF 映画を見すぎて、科学的手法を使用してソフトウェアの利点を最大化するというソフトウェア エンジニアリングの目的が薄れてしまっているのかもしれません。しかし、それは決して高度にインテリジェントな自己修復システムではありません。著者の意見では、この人工知能システムは、Nokia 携帯電話と Apple 携帯電話の比較と同様に、ソフトウェア エンジニアリングの別の次元であり、SRE モデルは、Nokia 携帯電話の価値を最大化するために現在のツール チェーンをどのように使用するかを解決します。人工知能システムに置き換えられるのではなく。おそらく将来的には、SRE が直接廃止され、運用保守システム全体がロボットに置き換えられるようになるでしょう。しかし、SRE は最終的にテクノロジーの歴史に深い足跡を残すことになるでしょう。

以上がSRE における自動進化の適用の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。