井戸の出典: 運用および保守の形状

編集者注: ジン ボスは、私が 2011 年にバイドゥに入社したときのチームの上司でした。彼は筋金入りのベテランです。この機会をつかむのは簡単ではありませんでした。彼は利益のために、業界でよくある質問をすべて質問しました。読者の。ジン親分は自由闊達な性格で、冗談も悪口もすべて書き留められており、主義主張もわかりやすい。堅実でハイレベルな「運用・保守フォーラム」の第１回、スタートです！

ゲスト紹介

Jingyuan 氏、左から 1 人目、元 Baidu 運用保守アーキテクト、元 Xiaomi運用保守担当者、元 Meicai CIO

一部の運用保守担当者は、同社は運用保守の価値についてほとんど知識がなかったと報告しています。運用保守の価値をどのように明確に説明しましたか。当時の会社へのメンテナンスは？

まず、運用保守の仕事の責任（運用保守が何をするのか、何を生み出すのか）と重要な指標（出力結果の測定）を企業に明確に説明する必要があります。安定性、安全性、効率性などの取り組み。どのような運営・保守プロジェクトが実施され、主要指標の達成をどのように積極的に推進していくか。

主要な指標には、サービスの可用性だけでなく、サーバー リソースの準拠率、サービス障害データ (障害分類、障害応答時間、平均障害回復時間、障害アラーム適用範囲)、サービス セキュリティ指標、サービス期間も含まれます。リソースなどが利用可能になります。

たとえば、完全な監視システムを構築します。

サーバー リソースの使用状況を監視し、標準を下回る使用状況のサーバーを見つけ、仮想化、コンテナ化などの手段を通じてリソースをリサイクルまたは再割り当てします。リソースの使用率を改善し、問題を解決します。アラームしきい値を設定し、P0、P1、P2、および P3 アラーム レベルを標準化する;監視システムは、アラームのマージ、インテリジェントな位置提案、アクティブなアラームの集約、および経時緯度アラーム分析を提供します。便利で迅速なアラーム応答と障害位置特定、アラームの改善、障害応答時間、障害回復時間、その他のサービスの計画の分類、平均障害回復時間の短縮、および障害アラームの適用範囲の向上

いくつかの意見業界では、クラウドや Kubernetes などのインフラストラクチャの台頭により、運用保守の職は徐々に排除されると考えられていますが、この見方についてはどう思いますか?

何年も前、当社の運用保守チームのスローガンは NO Ops で、ブログは noops.me でした。

運用保守の職が徐々になくなる、あるいは一部の職責がなくなるだろうと長い間言われてきました。システムの運用保守を例に挙げると、以前の経営陣はサーバーエンジニア、カーネルエンジニア、ネットワークエンジニア、CDNエンジニア、計算機室運用保守エンジニアなど20名規模のチームが必要でした。その後、パブリック クラウドの導入により、チームのメンバーはクラウド リソース管理者 1 名、CDN スケジューリング エンジニア 1 名、ネットワーク エンジニア 1 名、カーネル エンジニア 1 名の 4 名のみとなり、サードパーティが提供するリソースとサービスを管理およびスケジュールするだけで済みました。 -パーティー企業。

K8 とクラウドの普及と、研究開発コード エンジニアリングの継続的な成熟により、運用とメンテナンスがこのプロセスに関与することはますます少なくなります。導入フレームワークが成熟すると、運用と保守の人員を節約し、導入効率を向上させるために、第 2 レベルと第 3 レベルのサービスの導入は R&D セルフサービスに委ねられます。

科学技術の発展や時代の変化に伴い、ポジションが消滅するのは当たり前のことであり、タイムリーな調整と計画を立てることが思考の焦点となります。

企業が大規模にクラウドに移行している現在の環境において、現在の人材ニーズをより適切に満たすために、運用および保守担当者はどのような調整を行う必要があると思いますか?

クラウド環境においては、運用保守エンジニアは、よりビジネス指向、アーキテクチャ指向となり、業務範囲を拡大し、ビジネスの安定性を確保するためのキー人材となる必要があります。以前と同じで、アラームの監視のみに重点を置き、サービス展開の変更のみを担当する場合、間違いなく排除されます。

一方、専門化の方向に進んで、特定の分野（監視、ビッグデータ、K8s、データベースなど）の専門家になり、運用保守の研究開発専門家になることもできます。

人生に関するアドバイス、もっと副業を探してください。運用保守の仕事は人生のほんの一部にすぎません。

AIOps は数年前から大々的に宣伝されてきましたが、最近ではその人気は明らかに落ち着いてきています。企業は現段階で AIOps を導入すべきだと思いますか?どのような問題に注意すべきでしょうか?

スマート監視を例に挙げると、AI を使用して障害を予測し、インテリジェントに位置を特定する必要があるというコピーライティングを多く見てきました。今のところ信頼できる事例は見たことがありません。サービスの変化が速く、依存関係が複雑で、障害に影響を与える要因が多数存在するインターネット ビジネス システムでは、履歴データを通じて障害を予測することが実際に可能である場合。地震予知はやったほうがいい、数千年にわたる地震データの蓄積は大きな社会的価値を生みます。

AIOps を実行するための前提条件は、AI を真に理解し、機械学習とニューラル ネットワークの原理を理解することです。人工知能と同じくらい多くのインテリジェンスがあり、AIOps 機能はスローガンではありません。

chatGPT のような AI 機能は、将来的に運用保守業界の問題を解決できると思いますか?

たとえば、障害管理では、障害のある機器、データ、説明に基づいて、知識ベースや障害履歴データベースなどを通じて、障害に対して考えられる補助的な提案 (サジェストボット) が提供されます。

ところで、すでに chatGPT を使用できる場合は、このテクノロジをより多くの価値を生み出すことができる他の分野に投資してください。運用とメンテナンスの分野で常に無駄にしないでください...

業務プログラムの展開を研究開発に任せるべきか、運用保守に任せるべきかについては、多くの企業で議論が尽きませんが、この問題についてどう思いますか?

前述したように、第 2 レベルと第 3 レベルのサービスはすべて研究開発によって提供され、第 1 レベルのサービスは運用保守と研究開発によって順番に提供されます。運用と保守は現在のサービスを把握しており、変更点だけを把握しています。運用保守担当者が会社の設立当初に導入を行う場合、システムの開発と導入を改善し、担当するサービス アーキテクチャを制御するために、オンライン環境の標準化とサービス導入方法の標準化に重点を置きます。

セキュリティの問題とプロセスの問題は、システムを導入することで完全に解決できます。運用保守に関しては、何の価値も蓄積もない作業に執着しないでください。

(運用保守)業界に一番言いたいことは何ですか?なぜ？

「物理学は存在しませんが、私たちが考えている物理学は存在しないかもしれません。」 運用保守業界はもう存在しないかもしれません。AIOps、NOOps、または自分自身の夢を抱いている運用保守担当者はどれだけいるでしょうか。この業界を殺すか、この業界で殺されるか。

ツールの選択に関しては、自分で開発するか、オープンソースを使用するか、商用製品を使用するかをどのように決定しますか?

能力と時間があればオープンソースを使用し、能力と時間が限られている場合は商用製品を使用してください。お金と余裕があり、非常にうぬぼれているのであれば、独学に挑戦してみるのもいいでしょう。

あなたの会社にもマルチクラウド アーキテクチャがありますか?マルチクラウド シナリオではどの機能がクラウド ベンダーに依存すべきであり、どの機能が社内で構築されるべきだと思いますか?

当社はマルチクラウド アーキテクチャです。専用線やデータ通信機能はお客様ご自身で構築する必要があります。監視システム、データバックアップシステム、デプロイメントシステム、マイクロサービスコアコンポーネントなど、マルチクラウドをベースとしたパブリック機能を自社で構築し、残りをクラウドベンダーに任せることも可能です。

あなたの最も記憶に残る失敗は何ですか?それはあなたにとってどんなインスピレーションを与えますか？

長年にわたる運用とメンテナンスの結果、私たちは非常に多くの奇妙な障害に遭遇しましたが、その根本原因は想像を超えています。障害を回避するのは困難であるとしか言えず、障害の頻度、影響範囲、影響時間を減らすことを試みるしかありません。

つまり、パフォーマンスは障害の数や障害レベルではなく、障害の影響、障害の対応、復旧時間などによって決まります。

基礎技術の急速な発展に直面して、業界に入ったばかりの運用保守担当者と、この業界に長く勤務している運用保守担当者に向けたキャリアプランニングの提案はありますか?

極端ですよ～ 業界に入ったばかりの方は早めに転職することをお勧めします！長くこの業界にいる人にとって、技術分野への転職は比較的難しく、運用保守分野にそのことが強く刷り込まれています。他のテクノロジーに転職する運用保守担当者が多すぎますが、そのほとんどが運用保守の研究開発や運用保守のプロダクトマネージャーの職に就いており、副業を見つけたほうが良いでしょう。

従来の運用保守と SRE の違いは何だと思いますか?チームの変革の背後にある考え方は何ですか?

もう 2023 年です。このトピックについて話すことは、インターネットの運用と保守に対する NOC の監視義務を設定するようなもので、時代を逆戻りさせます。

5g 時代と同じように、SRE を変革するかどうか、SRE をどのように変革するか、SRE の変化をまだ検討している場合、2g を使用するか 3g を使用するかをまだ検討している場合は...時代によって淘汰される。

突然終わりが近づいているように感じますか?あはは、今回が「運用・保守フォーラム」の第1回目です。今後も業界リーダーの方々をお招きし、意見を共有していきます。さまざまな意見があるほど面白いし、考えるきっかけにもなります。一緒に考えていきましょう。心を開いて、何百もの学派の意見に耳を傾けてください。次回お会いしましょう！

以上が井戸の出典: 運用および保守の形状の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。