このトピックの終わりに: 運用保守の仕事ができなくなったというのは本当ですか?

先週の金曜日、Ma Chi と Lai Wei はオンラインで意見交換を行いました。議題は、運用保守職は本当にもう募集できないのかということでした。主催者として、私は発火者であり進行役でもあります:) 2人の退役軍人がそれぞれの意見を共有するのを聞くことで多くの利益を得ました。今日は忘れないように録画しておきましょう 生放送の振り返りです。

ツール プラットフォームについて

ツール プラットフォームは労働力の一部を置き換えます。これは実際には明白であり、これ以上説明する必要はありません。

しかし、ツール プラットフォームを構築するのは誰でしょうか?これはチェックしてみる価値があります。監視システム、CI/CD プラットフォーム、カオス エンジニアリング プラットフォーム、ミドルウェア サービスなどはすべてプラットフォームであり、PE と呼ばれるプラットフォーム エンジニアによって構築されます。 PE は明らかに多くのグループに分かれており、各 PE グループが担当するプラットフォームの数は限られています。この分散した PE チームは、インフラストラクチャ チームなどの大規模なチームに編成することも、複数のチームに分割することもでき、たとえば、エンジニアリング パフォーマンスに関連する PE チームを 1 つの部門 (パフォーマンス エンジニアリング部門など) に配置することもできます。 ）、データベース、ビッグデータに関わるPEチームは1つの部門（データ部門など）に配置され、安定性保証に関わるPEチームは1つの部門（運用保守部門など）に配置されます。

この組織の部門は会社によって異なるかもしれませんが、その関係はそれほど重要ではなく、重要なのは PE チームがどのように仕事を遂行するかです。 PE チームの中核は次のことを行う必要があります。

• 有用なプラットフォームを構築し、ビジネス R&D チームがセルフサービスを提供できるようにする
• プラットフォームはベスト プラクティスを蓄積する必要があります。プラットフォームはビジネスを満足させる必要がありますが、業界のベスト プラクティスも必要です。理論的には、ビジネス ニーズが業界のベスト プラクティスと矛盾する場合、可能な限り業界のベスト プラクティスが優先されるべきです。それが短期間で本当に不可能な場合は、計画は段階的に実行し、将来的には達成できるように努力しなければなりませんが、そうしないと、個別の事柄やアンチパターンの事柄が増えてくると、プラットフォーム側はますます不快になります。最後には圧倒され、打倒されて最初からやり直しになります。##ルールや規制を使用するのではなく、プラットフォームを使用して仕様を実装する方法を見つけなければなりません。Ma Chi が良い例を挙げました。彼らは次のような仕様を持っています。 「ビジネスプログラムは、状態データを保存するためにローカルディスクを使用しないことを要求しています。彼らはこれをレッドラインとは考えていません。法令は公布されましたが、コンテナがドリフトできるようにコンテナを定期的に再起動することがビジネス側に明確に伝えられました」 ！実際、AWS を使用したことがある人は、AWS 仮想マシンが時々不可解に再起動することを知っている必要があります。信頼性の低いインフラストラクチャに高可用性アプリケーションを提供するのはアプリケーション開発者の責任です。
• COE (ドメイン専門家) が、AWS 仮想マシンの進化を導く必要があります。なぜなら、データベースが得意なアーキテクトは Hadoop が苦手であり、Hadoop が得意なアーキテクトは可観測性システムが苦手であり、可観測性システムが得意なアーキテクトはカオス エンジニアリングが苦手である可能性があるからです。
• しかし、すべてのプラットフォームが一夜にして作成されるわけではありません。これらのプラットフォームがまだない場合はどうすればよいでしょうか?企業はまず COE を採用し、COE にプラットフォームの機能を構築しながらビジネス コンサルタントとして機能させるべきです。ビジネスは急速に発展していますが、プラットフォームの自社開発は遅すぎます。また、外部のサプライヤーにソリューションを求めることもできます。 COE自体も、状況に応じて外部の解決策を模索することができます。

外部サプライヤーについて

誰もが直感的に次のように感じます。欧米企業は SaaS サービスを購入することに積極的である一方、国内企業はオープンソースに基づいて独自のサービスを構築することに積極的です。国内の企業理念が良くないからでしょうか？あまり。中心的な問題は、国内の多くの分野で信頼できる ToB 企業や製品が不足していることです。 ToB 企業が当事者 A に以下を提供できると想像してみてください。

優れた高度な方法論

• 安定した使いやすい製品
• 優れた、安定した顧客の成功チームは、顧客がベストプラクティスをより適切に実装できるよう支援します。
• 価格の点では、A 社が独自に人材を採用し、独自に研究するよりも安価です。
• CXO の頭脳が壊れていない限り、 、間違いなくそのような外部サプライヤーを導入することを選択します。しかし、そんなToB企業が存在するでしょうか？これは大きな疑問符です。私たちはお客様に可観測性製品を提供し、そのようなサプライヤーになるよう努めるためにKuaimao Nebulaを設立しました。業界のToB仲間が一緒に働けることを願っています！

キャリア選択の問題をさらに詳しく説明すると、現在は特定のセグメントに優れたサプライヤーがいないかもしれませんが、3 年後はどうでしょうか?今から5年後はどうでしょうか？外国はすでに主導権を握っていますか？中国に有望なサプライヤーはいますか?すでにそれを持っているなら、兄弟、あなたはまだこのニッチな分野に専念し続ける勇気がありますか？事前に何らかの計画を立てるべきでしたか？

もちろん、私たちは将来の見積もりについて楽観的すぎるか悲観的すぎることが多く、時間の見積もりは通常、早すぎるか遅すぎるかのどちらかです。そうです、兄弟、それはあなたの判断次第です。

緊急障害対応について

OnCall障害対応は研究開発部門が対応すべきでしょうか?それとも運用・保守でしょうか？この質問は非常に興味深いです。 Ma Chi 氏は、オンライン障害の 80% は変更に関連していると考えています。変更は R&D によって行われ、R&D のほうが明らかにそれに精通しています。R&D が OnCall 障害に対応できるようにします。つまり、R&D は問題の 80% により速く対応できます。

ビジネス開発とはこのようなものです。データベースの変更、基本的なネットワークの変更、アクセス層の変更はすべて同じです。変更を行う人は、自分のサービスの障害アラームに対応する方が合理的です。

実は、これは次の 2 つの前提に依存します:

1. 監視と可観測性が十分に行われており、変更によって引き起こされた問題は、このプラットフォームを通じて時間内に発見できます。すべての企業が完全な可観測性システムを備えていることを願っています。
2. 変更によってもたらされた問題はすぐに反映されます。変更によってもたらされた問題が 1 週間後にしか現れない場合、変更を行った人が自分自身を疑うことは困難になります。

実際には、これを 2 つの状況で扱うことができます。変更後のサービスの安定性の監視は、変更を行った人の責任です。毎日の OnCall は別のシナリオであり、別個に扱う必要があります。では、毎日の OnCall は誰が行うべきなのでしょうか?障害位置の特定とストップロスに直接参加できる人でなければなりませんが、その理由は明白で、オンコール担当者がアラームを受信して​​他の人に連絡する必要がある場合、障害ストップロスの適時性が非常に低くなります。

したがって、まず第一に、アラームはさまざまなカテゴリで処理され、さまざまな担当者がさまざまなアラームを OnCall する必要があります。研究開発や運用保守にすべてを警告するのは無理があり、この絶対的な考え方は無理がある。

変更リリースについて

最終目標についてはコンセンサスがあり、それはビジネスの研究開発が自由にバージョンをリリースできるようにすることですが、私たちはそれを制御し、安全にリリースしたいとも考えています。そしてリリースしながらビジネスを保護したいと考えています。これにより、CI/CD システムには非常に高い要件が課されます。

気にしなければ、システムの最下層を変更するのは、マシンのバッチ上でスクリプトをバッチ実行するだけです。しかし、上記の要件を追加すると、作業はさらに難しくなり、体系的なプロジェクトになります。

ビジネスの研究開発側では、観察可能なポイントを作成し、システムを監視して問題を時間内に検出し、さらにはアラーム後にリリースプロセスを自動的にブロックする必要があります。 Blue-Green リリースとカナリア リリースには何らかの手段が必要であり、自動コード スキャンとセキュリティ スキャン機能も必要です。ツール システムは不完全です。変更を確実にロールバックできるように、やみくもに R&D を要求するのは不適切です。変更は安全です。 CI/CD の能力のレベルは、基本的に企業の技術力を知ることができます。

あなたの会社が依然として研究開発に運用と保守のための船荷証券を提供しており、運用と保守がオンラインで行われている場合、これが合理的かどうかを検討する必要があります。もちろん、上記のアプローチはよりインターネット指向であり、すべての企業に適しているわけではありませんが、このライブ ブロードキャストはアイデアを提供するだけであり、それについては自分で検討する必要があります。

もちろん、この理想的な状況を達成するにはどうすればよいでしょうか?この理想的な状況に到達するまでに、段階的にどのように取り組んでいくべきでしょうか。生放送では時間の問題は議論されなかった。自社の業務がKubernetesでの運用に適している場合は、Kubernetesを利用したシステムの構築が比較的容易であり、すぐに対応することができます。企業のビジネスを物理マシンまたは仮想マシン環境で実行する必要がある場合は、まず統合された変更リリース プラットフォームを作成し、次にギャップを埋めて徐々に改善します。

コスト最適化について

ゲストのお二人は多くは語らなかったが、この件については全員が非常に慎重だった。全員に注意してください:

1. 人材はハードウェアよりも高価です。5,000 万の人件費がかかり、ハードウェアのコストが 4,000 万節約されるようなことは絶対に行わないでください。
2. ビジネスに十分な冗長性を残してください。コンピューティングの予備を用意してください。リソースが不足していてバッチの予算が承認されない場合、容量によって障害が発生すると、顧客エクスペリエンスが損なわれ、世論は否定的になり、利益が損失を上回ります。
3. 馬鹿げた例は、300万元のハードウェアコストを節約するために3,000万で購入した場合、ボリュームに抵抗できず、本当に損しました

概要

現段階では、プラットフォームシステムはまだそれほど完成していませんが、セルフサービスプラットフォームCOEを利用して運用保守システムを構築するためのBP(ビジネスパートナー)のアーキテクチャは信頼性が高く実装可能と思われます。将来的に、プラットフォームが十分に充実すれば、BP の人員は削減できます (BP は COE を行う能力を徐々に獲得してきました)。プラットフォームが完成し続ければ、COE は引き続き削減できます。その後は、運用とメンテナンスや研究開発は必要ないかもしれません。

以上がこのトピックの終わりに: 運用保守の仕事ができなくなったというのは本当ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。