Tuyou Zou Yi: 中小企業をどのように運営、維持するか?

質問: 中規模企業の運用保守チームは通常、それほど大きくありません。限られた人員をどのように編成していますか?共有できる経験はありますか?みんな？

人材構造は徹底的に最適化されなければならず、
1. 専門的な制作および研究の人材を導入する必要があります、制作と研究を利用してチームの価値ある成果を推進します。現在、Tuyou の運用および保守セキュリティ チームは、生産研究と従来の運用および保守の比率がほぼ 1:1 となっています。
研究と運用を統合する組織モデルを構築するには、フル機能のエンドツーエンドのハイブリッド チームを形成する必要があります。 Tuyou の現在の運用および保守セキュリティ チームは、プロダクト マネージャー、研究開発リーダー、フロントエンドおよびバックエンド エンジニア、サービス運用エンジニア、運用および保守エンジニア、IT エンジニアで構成されています。
2. 相互信頼、一貫した目標、情報共有、分散化を中心とした機敏な文化的雰囲気を構築します。機敏な文化的雰囲気を通じて、不確実性に対処できる機敏な組織を形成することができます。

Q:チームの人材レベルが低いために、アイデアの実行が遅い、または実現が難しいという問題に遭遇することがあります。この問題はどのように解決しますか?

1. 忍耐強く、チーム内で繰り返しを繰り返してください。これは次のようなものです。トランプ。良いハンドが得られることは期待できません。ゲームに勝つには、常にカードを出し入れし、最後にカードをまっすぐに揃える必要があります。 新入社員の基準は、現在のチームメンバーの70%以上のポテンシャルを持っていることです。基準を満たしていない場合は、むしろ採用しないほうがよいでしょう。採用には慎重でなければなりません。人を育てるには慎重に。
2. チーム リーダーはチームの最高人事責任者である必要があり、才能のある人材を見つけるために率先して行動しなければなりません。私は過去 4 年間に BOSS ダイレクト リクルーティングでおそらく 20,000 人近くの人々と話をしました。そして、次のようなことを読んだはずです。 20,000 件以上の履歴書を作成するのは、中小企業の運用保守リーダーにとっては難しいかもしれません。
3. 集合知を解き放つための基本的なサポートとしてアジャイル組織を使用します。
4. 私のチーム変革実践の共有について: https://tuyoo.feishu.cn/docx/doxcnGMuijglK6NdENYC2vD7KKh

Q: 特に同意するとおっしゃいました「ゆん」 記事「Dimensionの未来はプラットフォームエンジニアリング」の視点によれば、貴チームも生産・研究型の充実した組織であるとのことですが、ビジネスの研究開発においては、クラウド ベンダーが提供するプラットフォーム製品を直接使用する場合と比較して、あなたのチームはデルタ ゲインを何から得ていますか? この質問に答える前に、ホイール製造と外部調達サービスについての理解を詳しく説明したいと思います。

実際、当社は外部調達または自己調査を行っています。かなりシンプルな判断ですが、

のインプット/アウトプット比率に注目します。それが標準化されており、投資が巨額である場合、自分たちで解決できない場合は、問題を解決するために、外部のサードパーティのサービスや製品を使用するように努める必要があります。質問、 私たちは、事業部門にどのように適切にサービスを提供するか、また、提供するサービスの結果と品質にもっと関心を持っています。私たちはそうではありません。この機能が当社独自のものであるか、サードパーティのサービス機能であるかについてはあまりにも心配しています。 それが私たちに役立つ限り、サービスの品質と効率を向上させるために、私たちは吸収して統合することに非常にオープンな姿勢を持っています。 この制作・研究チームが私たちにもたらす利益についての質問に答えましょう。各企業には独自の特性やカスタマイズされたシーンの要件があります。これらのことは外国製品では完全にはカバーできません。エンド チーム エンド チームは、実際には、チーム全体にいくつかの非標準的な問題を解決する能力を与えます。この能力は実際には非常に重要であり、チームの価値実現を大きく左右します。

さらに、運用と保守の未来はプラットフォーム エンジニアリングであるについての私たちの理解について話しましょう。プラットフォーム エンジニアリングについての私の理解には 2 つの重要な要素があります:

1. プラットフォーム エンジニアリングは対象は主に業務部門であり、運用保守ではない
2. プラットフォームエンジニアリングはセルフサービスである プラットフォームエンジニアリングによって生み出される製品やツールは、主に業務部門向けのセルフサービスである必要がある

私たちのチームの変革の探求は主にこの 2 つの要素に基づいていますが、理論レベルが十分ではなく、プラットフォーム エンジニアリングの概念を明確に提案できていません。私たちのゲーム運営とメンテナンスにおける大きな問題点は、CDN のアップロードとリリース、ゲーム設定の更新、定期的なサーバーの起動と停止など、ゲームの運営とメンテナンスの日常業務である、些細な事柄がたくさんあることです。おそらく、ゲームの運用保守の常識では、自動化ツールを作って運用保守の人的効率を向上させ、従来の運用保守を変えることを考えるでしょう。人間の生身の状態やスクリプトを書いている状態をWEBOPSの状態に置き換えるこの感覚 まだレバレッジ比率が低すぎて、運用保守も解放されていないため、これらの問題を解決する過程で、私のプラットフォームエンジニアリングの概念に対する独自の理解が生まれました現在、ゲームの運用とメンテナンスの日常業務の 50% はプロジェクト チームによって実行されています。私たちが提供するツールを使用したセルフサービスは、このアイデアに触れた後、認知的一貫性が高いと感じたものです。プラットフォームエンジニアリングの。したがって、運用保守の未来はプラットフォームエンジニアリングであり、セルフサービスのメリットを味わい、人力による運用保守の苦労を経験した学生は深い共感を覚えると思います。

質問: コスト削減には多大な労力と努力が必要であり、多くのコストを削減する必要があるとよく言いますが、同社は賞状を発行し、この FinOps プロジェクトが最も効果的であることを示しました。クラウド上およびクラウド下でのインフラの構築において、あなたのチームは会社に大幅なコスト削減をもたらし、会社から多大な報酬を受け取りました。関連する経験を共有できますか?

FINOPS に関しては、私は普段、業界の専門家や先生方と交流や議論をしているのですが、チーム自身の実践と合わせて、個人的には FINOPS の導入は難しいと感じており、 「難しいのは上司を変えることだ。現時点では業界はまだ技術的な実現やコンセプトの衝突の段階にあり、どちらがより専門的でより標準化されているかを比較する段階にある。個人的にはFINOPSに影響を与えることはできないと感じている」上司の認識は基本的に無価値か極めて価値が低いものであり、やるかやらないかに違いはありません。 FINOPS の分野についてはあまりコメントしたくありません。私たちはコストの最適化に焦点を絞りました。私たちのチームでは、コストの最適化に OKR を設定していません。私たちは常にリーンの概念を使用して作業を進めてきました。 「リーン」には核となる概念があり、「価値を生み出さないものはすべて無駄である。無駄を排除し続ける必要がある。これにより、作業プロセス中に動的コストの最適化を行う必要がなくなります。」数億ドルを節約したコストの最適化の多くは、上司の目には正しいものである可能性があります。以前は無駄が多すぎましたが、現在は無駄を排除するだけであり、当然価値があるとは認識されません。

私は、コスト最適化の実践におけるいくつかのポイントを個人的にまとめました。

1. コストを削減し、コストを削減するための単純なキャンペーンではなく、コストの最適化を継続的に導くために、リーンの概念を使用する必要があります。効率を高めます。
2. 価値観についてのコンセンサスを得るには、総務部、財務部、その他の規制部門などの関連部門とのコンセンサスを得る必要があります。
3. コスト最適化の計算モデルは複雑すぎてはいけません。モデルの計算が複雑すぎると、合意に達するのが難しくなります。
4. データは財務基準に従って統一的に検証される必要があり、技術的な観点からそれを当然視することはできません。

編集者注: ゾウ氏はコストの最適化を行っています。具体的な削減額は最終的に財務部門によって計算されます。個人的には学ぶ価値があると思います。多くの企業のコスト最適化は信頼性の欠如により、上司は安心感を得ることが難しくなります。

質問: これは古い質問です。運用および保守チームは常に会社のビジネスの背後にあり、ビジネスから比較的遠く離れています。ビジネスをより良くサポートするにはどうすればよいですか。 ? または、運用と保守の価値をビジネスにどのように説明しますか? どのような提案がありますか?

価値を具体的に反映するにはどうすればよいですか? 運用保守チームが価値を反映したい場合は、まず サービス意識 を持ち、それから、サービス体制を構築し、次は辛抱強く改善を続けることで好循環を生み出し、時間を味方にします。

このセクションでは、私たちのチームのサービス システムを構築するためのガイドラインを簡単に共有します。私たちは顧客中心で、安全、信頼性、効率的、低コストで持続可能なサービスを構築します。サービス運用を通じて価値を生み出し、製品やツールを通じてサービス運用を実行し、継続的に改善します。このガイドラインの概要では、運用と保守、生産と研究、運用の 3 つの機能的役割をチーム内で深く統合しています。価値はサービス操作の出力を通じて反映されます。テクノロジーの分野で働く人は、サービス運用の重要性をなかなか認識し​​ていないことが多く、技術運用や製品運用についてはよく話しますが、サービス運用について話す人はほとんどいません。これは、私たちの技術的背景に対する慣性的な認識に大きく関係しており、私たちは自分の専門分野の観点から表現することが多く、サービスを提供する人々の観点から自分の価値を見ることはほとんどありません。多くの人はサービスというと、単にお茶出しや用事をこなすといった役割を思い浮かべるかもしれませんが、サービスを提供することにさらに抵抗を感じます。しかし実際には、どのチームもサービスチームです。たとえば、当社のサービス プロジェクト チームはエンド ユーザーにサービスを提供し、エンド ユーザーは自分の仕事分野の他の顧客にサービスを提供する場合があります。したがって、サービスを提供することは非常に重要なことです。顧客に適切にサービスを提供し、顧客が結果を得るのを支援することによってのみ、あなた自身の価値を真に反映することができます。

続きを読む

• 運用と保守に関する百回フォーラムの第 5 回: Du Xiaoman と Chen Cunli: 20 歳の「司令官」が運用と保守について語ります。パフォーマンスと成長
• 運用とメンテナンス フォーラムの第 4 回: Shao Haiyang が再び: Linux 歴 25 年のベテランが DevOps の 8 つの名誉と 8 つの恥辱について語る
• 運用保守フォーラム第 4 回 第 3 号: Flashcat Lai Wei: 運用保守の仕事を安定させる方法
• 運用保守 Baijia フォーラム問題 2: 宿題ヘルパー Nie An: 運用と保守を変革する方法、宿題を聞く Bang の OPaS アイデア
• 運用と保守フォーラム No. 1: Jingyuan: 運用と保守のジオメトリ