Yun Shao Haiyang の別ショット: Linux 歴 25 年のベテランが DevOps の 8 つの栄誉と 8 つの恥辱について語る

インタビューや原稿依頼を通じて、運用保守分野のベテランを招き、深い洞察を提供し、意見をぶつけ合いながら、先進的なコンセンサスと推進 業界はより良い方法で前進する必要があります。

今回は、Linux 歴 25 年のベテラン、Youpaiyun Technology の Shao Haiyang 氏をお招きします。Shao 氏はテクノロジーに執着し、一歩ずつステップアップしていきます。これは一般的な運用保守担当者の典型的な成長です。パスさん、今日のインタビューがあなたにインスピレーションを与えられれば幸いです。

これは、現実的でハイレベルな「 Operation and Maintenance Hundreds Forum 」の第 4 回目です。始めましょう!

こんにちは、シャオさん、まずは自己紹介をして、誰もがあなたのことをよく知り、あなたの背景を理解できるように、あなたの履歴書と現在の状況について話してください。以下のインタビューの内容です。

私は Youpaiyun Technology の Shao Haiyang です。1998 年から Linux をほぼ 25 年間使用しています。Linux のベテラン (ベテラン) です。システム操作メンテナンス/アーキテクト、DevOps の 8 つの栄誉と 8 つの恥辱の提唱者、アマチュア ライター、(有罪) システムの最適化とネットワーク サービス管理、Linux システムのカスタマイズ、CDN アクセラレーションとセキュリティ防御に熟達し、高性能のインターネット ネットワークとアーキテクチャの設計が得意、仮想化された KVM と OpenStack クラウド プラットフォーム、K8S コンテナ クラウドと Ceph 分散ストレージ、その他の新しいテクノロジー、コミュニケーションと共有を好み、コミュニティで積極的に活動し、オープンソース活動の組織と普及に積極的に参加しています。

運用保守の分野では、各社が独自の運用保守ガイドラインや運用仕様を策定すると思いますが、貴社の経験談など参考になれば幸いです。

Youpaiyun は、クラウド ストレージ、クラウド配信、クラウド処理サービスを提供する会社であり、プログラマブル CDN サービスを提供する中国初のプロフェッショナル クラウド サービス プロバイダーでもあります。サービスは断続的であるため、クラウドの運用とメンテナンスには次のようなルールや原則があります:

まず安定性を確保してから、

# を最適化します。 ##過剰な設計や時期尚早な最適化は、ダウンタイムの増加を避けるために、まずシステムのスケーラビリティと高可用性の向上に重点を置く必要があります。このプロジェクトは「最初に完成、次に完璧、次に完璧」という実装戦略を遵守し、「最初に使用可能、次に使いやすく、次に使いやすい」という実装戦略も採用しています。

信頼性の高いテスト基準と時間検証を提供します

新しいテクノロジをアーキテクチャに導入する前に、新しいテクノロジの安定性と十分な長期テストを確保する必要があります。そしてさらに重要なのは、運用および保守エンジニアリングで開発されたツールチェーンの完全性がなければなりません。オンラインでの手直しや変更による油断が、すでに失敗の引き金になっている可能性があります。

制御可能な自動化手法を使用して効率を向上させる

自動展開、自動オーケストレーション、自動検査、自動アップグレードなどの自動化手法がクラウドの運用と保守で使用されることが増えています。これはクラウド コンピューティングの時代に適応する傾向ですが、機能が大きくなると責任も大きくなります。自動化による雪崩や雷の群れの影響に注意し、グレースケール/ブルー グリーンの展開やさまざまなテストで適切な作業を行ってください。

シンプルにしてすべてを監視

シンプルにして、複雑になりすぎないようにしてください。傾向分析情報としては、一般的な異常警報のほか、経営指標、市場指標、売上データ、コストなどを利用できます。定期的にポーリングして各傾向データの山と谷を確認すると、洞察を得ることができます。

予算重視の運用保守

通常、最も多くの出費をするのは運用保守チームであり、予算が不足しているため、資金がなければ運用保守を行うことは困難です。企業の事業規模は、企業の事業が停滞しているか爆発的な成長がなくなっていない限り、そのような課題に直面した場合、運営と保守はコストを削減して利益を上げ、収益を増やして支出を削減し、新しいものを使用する方法を学ばなければなりません。エネルギー効率を向上させる技術。

シナリオ指向のインテリジェントな運用とメンテナンス

高同時処理からビデオトランスコーディング、高性能並列コンピューティングから大規模ネットワークに至るまで、さまざまな負荷シナリオが求められます。これらのさまざまな負荷シナリオには、ネットワーク帯域幅、さまざまな処理、および IO に対するさまざまな要件もあります。インテリジェントな運用と保守には、ビジネスを深く理解し、さまざまなビジネス シナリオのニーズを満たすためにリソースとアーキテクチャを合理的に割り当てる必要があります。

継続的統合およびリリース システム

継続的リリースには、グレースケール リリース、テスト リリース、ローリング リリース、ロールバック リリース、その他のシナリオが含まれており、各シナリオが制御可能であることを保証します。 。

誰でも交代できるようにする

鉄壁のキャンプでは、人々が動き回ることは通常のことです。共有ドキュメントで適切な仕事をしましょう。管理と従業員間の知識の伝達と共有、理論的には誰もが置き換え可能であり、誰も会社の天井になるべきではありません。

成長はあなた自身の仕事ですが、適切な分野、適切なプロジェクトの機会、適切なチーム、適切なメカニズムがあれば、エンジニアはより速く成長し、チームはより効果的になります。運用および保守の学生の成長を促進する方法について体系的に話していますか?

同社は従業員が自らのスキルを向上させ、成長を促進することを常に積極的に奨励してきました。

• 毎月のオープンデー: 社内の技術委員会が定期的に講演会を開催します。最先端の研究から得られる成果には、テーマ、焦点、応用シナリオ、できれば例が必要です。
• 毎週の共有ミーティング: すべての開発者は、新しいテクノロジーを定期的に共有したり、直面している問題や考えていることについて話したりすることが奨励されています。共有コンテンツはドキュメントやビデオ アーカイブとして形成され、評価に基づいてアーカイブされ、ボーナスとポイント インセンティブが与えられます。
• 企業報奨金プロジェクト: 企業または従業員自身がプロジェクトを開始でき、技術委員会による審査を通過した後、チームを編成してプロジェクトを完了できます。出力されたドキュメント、データ比較、技術を共有すると、それに応じたプロジェクトボーナスが得られます。特許申請には対応する特許ボーナスがあります。
• 個人的な影響力を高める: 個人的な影響力を高めるために、記事や講演を出版することでエンジニアリングの経験を共有したり仕事の経験を整理したりするために従業員が出かけることを奨励し、聴衆のフィードバックに基づいて原稿料や講演料のインセンティブを提供します。
• 新聞、雑誌、その他の紙の本を購読して、最新の動向を学びましょう。部局ごとに図書購入費として一定の補助金が割り当てられています。

Youpai クラウド運用保守チーム内のトレーニングには次の内容が含まれます:

• 「天井を支持板に変える」: 新しい人材を育成する管理の役割に身を置くあなたが会社のボトルネックや従業員の天井にならないように、新しい人が新しいことに挑戦し、失敗に対処することを奨励し、自分のスキルと実務経験を高め、信頼し、助け合い、刺激し合うでしょう。驚きを生み出し続ける。
• 「自動化ツール」を作成する: 自身の経験を活用して、ビジネスをプログラム モデルに抽象化し、自動化されたスクリプトの作成または作成をトレーニングし、チームの作業効率を向上させ、従業員が学習にかかるエネルギーと時間を節約できるようにします。その他の新しい知識;
• 「高精度でプロフェッショナルな」プロジェクトに取り組む：最新の知識調査と実現可能性分析を事前に準備し、公開トレーニング用の文書にまとめてから、チームに引き渡します。・徹底的なリサーチと実践、生産性への変換、現場経験の蓄積とフィードバック・改善 ドキュメント化の好循環
• 「知識の共有」を積極的に推進：様々な事例と「ピット」を整理Wiki ドキュメントに変換します。ドキュメントの共有を通じて、講義が定期的に共有され、従業員は高品質で読みやすい記事を書くことが奨励されます。強力なドキュメントと率直なトレーニングにより、魅力と自信が高まります。
• 「参加」を奨励します。 「オープンソース交換」: 同社は従業員に外出して技術交換カンファレンスに参加することを奨励しています。密室での作業は時間と労働集約的であり、指導を提供するのは専門家ほど優れていません。また、書籍の購入、チーム構築活動、コーヒーブレイク文化のための資金も提供されます。

運用保守エンジニアの典型的なキャリア パスの 1 つは、マネージャーになることです。ですが、マネージャーと上級オペレーターでは、保守が解決しなければならない問題はまったく異なります。管理職になったばかりの上級保守保守の方々に、ご自身の経験をいくつか教えていただけますか?

管理職に就いたばかりの皆さんに提案したいのは、残っている技術的負債と在庫を整理し、タイムリーに人材スキルを育成することです。進歩の余地をさらに大きくするには、私の共有「 DevOps の 8 つの栄誉と 8 つの恥辱 」を参照してください。

• 1. 構成可能であることを誇りに思い、ハードコーディングを恥じる
• 2. 相互提供を誇りに思い、単一点を恥じる
• 3. 誇りに思ういつでも再起動できることを誇りに思い、移行できないことを恥じる
• 4. 全体的な配信を誇りに思い、部分的な配信を恥じる
• 5. 無国籍であることを誇りに思い、無国籍であることを恥じるstateful
• 6. 標準化を誇りに思い、専門化を恥じる
#7. 自動化されたツールに誇りを持ち、手作業と人間の肉体を恥じる
• #8. 誇りに思う
• スキル ツリー内のタレント ツリーのインベントリは、主に人材と協力して、人材の 9 正方形グリッドを分割することです (開発または運用の場合)。メンテナンス、左側のパフォーマンスをポテンシャル、パフォーマンスに置き換えます。営業の場合）、試されるのは、従業員のあらゆる側面を分析し、従業員を有効に活用する方法を知るマネージャーの能力です。

従業員のモチベーションを高めるために会社の OKR 目標管理と組み合わせると、目標を収集しながら次のこともできるという利点があります。

• 個人の自発性を刺激し、従業員の革新と反省を奨励します。
• 相対的な結果をテストし、困難な課題と突破口を奨励します。
• 協力し協力する能力を評価し、奨励します。従業員があらゆる側面を調整し推進する; すべてのシナリオで問題を解決することは不可能である 過去数年間観察した結果、どの企業が Kubernetes に適していないと思いますか?そのような会社の概要とその理由を説明してもらえますか?

Kubernetes は、これまでのところ Devops のエンジニアリング アプリケーションのベスト プラクティス (とてもおいしい) を表していますが、クラウド CDN エッジ サーバーやデータ センターなど、すべての状況に適用できるわけではありません。分析プラットフォームである Ceph 分散ストレージは主に物理マシンに基づいています。したがって、次のような適切なシナリオをいくつか見つけて、最初に試してみることをお勧めします: オフピーク時間のためマシン リソースが大幅に浪費されている;

CPU、ディスクおよびネットワーク IO は集中的ではありません;

永続ストレージやリソースのプリエンプションは必要ありません;
• ソフトウェア アーキテクチャはマイクロサービスによって変革されました;
• ビジネス処理プログラムは、定期的かつ弾力的な拡張 ;
• 運用保守と研究開発は最も密接なパートナーですが、貴社では業務の境界をどのように分けていますか?また、この 2 人のキャラクターが緊密に連携し続ける方法について、経験を共有してもらえますか?

運用保守エンジニア = 戦闘に突撃する一般人 ソフトウェア エンジニア = 戦闘テントに座る戦略家

#理論的には優秀ソフトウェア エンジニアは、ビジネス ソフトウェアのパフォーマンスの監視など、運用保守エンジニアの仕事の一部 (またはすべて) を実行できます。プログラマがプログラムに多数のフックやプローブを挿入した場合、データをカウントできます。運用と保守の面倒な監視。たとえば、プログラマがプログラムを設計するときに、サブデータベースとテーブルを考慮し、大規模な同時実行と分散設計を考慮します。そうすれば、運用と保守はマシンを水平に拡張できます。ソフトウェアにそれほど多くのバグがなければ、運用と保守はマシンを水平に拡張できます。 、if はたくさんあります...しかし、現実は残酷で、特に中国ではそのような高レベルのプログラマーが少なすぎて、誰もがビジネス機能の実装に忙しく、ドキュメントやコメントを書く気すらありません。徹底的に考えることができるということはもちろんのこと、運用保守においても、多くの優れた成熟したオープンソースソフトウェアに触れ、そこから優れたソフトウェアの設計方法を学ぶことができます。標準の syslog またはログを通じて監視できます。そのため、上級運用保守担当者は次のことを行います:

事前計画に積極的に参加し、開発に協力して訓練を実施し、展開を自動化し、アーキテクチャの改善を支援します。

合理的な要求とリソースが必要であり、問​​題が発生する前に防ぐための予算を確保することが最善です。

オンライン監視、障害レビュー、およびチーム全体へのフィードバックにより、全員が次のことを行う必要があります。
• もちろん、上記の運転維持管理能力を実現するには、集中して学び、過去と未来をつなぎ、チームを調整し、実践する必要があります。その頃には、運用保守は物事の結果に責任を負うのではなく、プロセス全体を主導し、調整する役割に変わります。もちろん、ここでいう能力とは、スキルだけを指すのではなく、事業を理解し、会社の経営層からプロジェクト全体やリソースの配分やコントロールに向き合う能力を指します。したがって、運用保守エンジニアは、実際にはソフトウェアエンジニアを補完するものであり、人それぞれ能力や重点が異なるため、全員が一致団結して戦いに勝つ必要があり、それがなければ誰もやっていけない、これが共通の育成プロセスです。そして進歩です。
• 最後に、私の個人的な意見: アーキテクトは個人の役割ではなく、チームの総称である可能性があります。

戦闘に突撃する必要はありません。全体的な状況の概要を把握し、すべてのリソースの戦略を立ててスケジュールを立てることができます (運用および保守アーキテクトの役割)

チームを率いて団結し、高レベルの建物を構築し、以下に基づいてソリューションを実装できる

会社のビジネスの方向性と深さを把握し、協力関係を交渉し、コストを管理できる(ビジネスアーキテクトの機能)
• ##運用保守は複数の他部門とのコミュニケーションや連携が必要です。さまざまな観点から、チームの目標や関心事が一致していない可能性があり、連携がスムーズではない場合があります。プロセスをスムーズにするために使用した工夫は何ですか? ?

実のところ、コミュニケーションがうまくいかない理由のほとんどは、結果が予測できないことにあります。あなたは冗長性について話し、彼は予算について話し、あなたは構造について話し、彼は建設期間について話します。誰もがそれぞれの立場や困難を抱えていますが、結果に対しては誰も責任を負いません。仕事の中で、障害が発生したとき、さまざまな部門の協力がこれまでになく団結し、戦闘効果が最も高まることに気づきました。したがって、コミュニケーションとコラボレーションの鍵は次のとおりです:

チームワークと明確な責任の両方が必要です

• 部門間の事前コミュニケーション中に、プロジェクトの期待、コスト、影響要因、障害の結果、および責任者を決定します。
• 障害後のレビュー中に、障害の原因に基づいて、「合格」合理的な証拠を備えた「出費」であると同時に、警告を受け入れて埋め合わせをする必要があります;

たとえば、10 W のオンライン同時実行機能を提供するには、冗長な帯域幅とその数が必要です。冗長化サーバ×2の冗長化 予算不足で予算を半分にした場合の結果と責任 人材不足、ソフトウェア設計の甘さなど パフォーマンス監視により異常指標の影響と責任者を発見 もちろんアラームが発生した場合は対応が間に合わない場合、人間による操作の失敗も運用保守にカウントされることは理解できます。障害文化とは、問題に注意を払い、物事に注意を払うことを意味します。それ自体、人の問題ではなく問題です。誰もが失敗を経て成長し、復習の中で強くなる。

運用保守作業の最も重要な目標は何だと思いますか?これらの目標をどのように達成しましたか?

運用保守の自動化;

監視の正規化;

ログの可視化!

長すぎるので詳細は省略しますが、「 クラウド運用保守の啓発とアーキテクチャ設計 」

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

Youpaiyun は通常、車輪を再発明することはありませんが、まず車輪を有効に活用するか、より便利になるように車輪を修正することは間違いありません。

• 自社開発のクラウド処理ソフトウェアなど、要件を満たすオープン ソース ソフトウェアが見つからない...
• オープンソースソフトウェアにはバグや問題があり、コミュニティは短期的には進歩できないが、ビジネスは急務であり、atsのメモリリーク問題など、自己研究でしか解決できない...
• オープンソース ソフトウェアの機能特性は会社のビジネスと一致していないため、ソフトウェアを変更する必要があります。たとえば、nginx のアンチホットリンク モジュールを顧客に合わせてカスタマイズする必要があります...
• 設計目標オープンソース ソフトウェアは高尚すぎて汎用性が高いですが肥大化しています。特定の小さな機能だけが必要な場合は、パフォーマンス プローブをどこに埋め込むかなどの派手な機能は必要ありません...
• データ保護要件がある場合、またはプライバシーがある場合...

クラウド ネイティブ アーキテクチャの下で、パブリック クラウドに移行する企業が増えています。 SREチームが変わった？チームの価値をどのように強調すべきでしょうか?

パブリック クラウドは IaaS ベース、コンテナ クラウドは CaaS 中間層、クラウド ネイティブは SaaS アプリケーション層として機能し、クラウド エコシステム全体は日々変化しています。 SRE チームの中核機能は、性的能力計画、指標モニタリング、高可用性および分散型弾力性設計により、クロスプラットフォームおよびクロス部門の機能補完性、チームのコラボレーション、継続的な改善、

• 事前の計画に積極的に参加し、開発に協力して訓練を実施し、アーキテクチャの改善を支援する;
• 可用性要件、冗長リソース、およびリソースを合理的に引き上げる問題が発生する前に予防するための予算を確保することが望ましい。
• オンライン監視、障害を分析してチーム全体にフィードバックし、上層部と下層部が連携して改善を行うよう強制する。

チームの価値は、常に新しいこと、新しい挑戦を受け入れ、井の中の蛙にならないように自分たちの強みを活かせるかどうかにかかっています。それはぬるま湯で茹でる蛙の問題ではありません。革新や転覆が起こるとき、私たちはまだまだ時代の流れから切り離せない。

個々の運用保守エンジニアにとって、SRE の変革の道筋は何でしょうか?何に注意すればよいでしょうか？

技術分野

抽象的なビジネス モデル、標準化されたコンポーネント、カスタマイズされたスクリプト、自動展開を学び、全体的な効率を向上させます。
ログの収集、ログの分析、視覚化を学び、運用とメンテナンスの監視と早期警告アラートの効率を向上させます;
• 1 つまたは複数の言語を習得し、慣れることは、言語の成長と向上に役立ちます。戦闘効果;
• 頻繁にメモを取り、過去を見直して新しいことを学び、学習と思考を組み合わせ、蓄積することを学び、1 つの例から推論を導きます;
• 困難に立ち向かう勇気を持ちましょう。新しいテクノロジーを学び、どうしても勝てない場合は学ぶ;

非技術分野 #

• 学習能力には幅広い知識が必要です;
• コミュニケーションの観点から、顧客の正確なニーズを理解します;
• 技術的なリスク、人件費、スケジュールなどのコスト、トレードオフ。
• コミュニティ活動、積極的な共有、雄弁さとコミュニケーション スキルの行使;
• 自分の影響力を高め、他の人たちとともに歩むことを学び、より多くの友達を作ります;

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

まず、仕事が人を選ぶのではなく、仕事を選ぶのは人です、何かに興味があり、10,000時間近く本気で勉強した人であれば、 、彼は実際に何でもできます。たとえば、私が卒業したときは、複合的な才能に重点が置かれており、運用やメンテナンスなどというものはありませんでした。私たちは (DIY) マシンを構築し、Linux オペレーティング システムを独学するだけでなく、プログラミングを学び、インターネット、フォーラム チャット ルームなどの独自のプログラムを作成しました。Linux は、革新的で楽しく、優れたオープン ソース ソフトウェアを毎日私たちにもたらしてくれるので、私たちは心ゆくまで遊んだり学んだりする情熱を維持することができます。インターネットの台頭により、運用保守ディレクターになるのは実際には自然なことです。実際、それに加えて、プリセールスやテクニカル サポートにも異動し、市場に出張し、スピーチのトレーニングも頻繁に行ってきました。本当のマスターとは、何も学べず、多くのスキルを持っているが自分自身を圧倒せず、ビジネスを理解し、開発できる運用および保守エンジニアです。

運用保守担当者にとって最も重要な資質は何だと思いますか?新しい運用担当者や保守担当者にメッセージをお願いします。

最も重要な能力は表現力とコミュニケーション能力だと思いますが、運用保守そのものに必要な技術的予備力、実践力、プログラミングスキル、学習能力を排除するものではありません。運用と保守は依然として主にコスト支出の立場であることを考慮すると、難解で曖昧なパフォーマンス指標とボトルネック指標を直感的なチャート表示に使用して、上層部からの継続的な投資を得るにはスキルが必要であり、その後、同僚や兄弟部門と対峙する必要があります。仕事を調整し推進するためにあなたの影響力が必要です。これができるなら、それはあなたがリーダーシップを発揮する能力を持っていることを意味し、将来何をするにもより高いレベルに達し、全体的な視野を持って調整できるようになります。プロジェクト全体を計画し、目標、人員、建設スケジュール、リソースを合理的に割り当て、管理します。

以上がYun Shao Haiyang の別ショット: Linux 歴 25 年のベテランが DevOps の 8 つの栄誉と 8 つの恥辱について語るの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。