運用および保守 100 フォーラムは、インタビューと原稿の招待を通じて、運用および保守の分野のベテランを招待し、深い洞察を提供し、意見を共有します。形成への展望 いくつかの先進的なコンセンサスは、業界がより良く前進することを促進します。
今回は、Wang Mingsong 氏をお招きし、業界で広く認知されているクラウド ネイティブ アプリケーション実践の「4 つのルール」を提唱しました。 2019 年から、Boss Wang の会社の IDC ビジネスはすべてクラウドに移行され、規模は小さくありませんが、SRE チームは非常に小規模で、NetFlix に似ています。この講義では、シニアのクラウド運用と保守がどのように行われているかを見てみましょう。
今回で第7回目となる、地に足のついたハイレベルな「運用保守フォーラム」を始めましょう！
始める前に、Boss Wang に自己紹介をお願いします。あなたの職歴、特にクラウドの使用経験について話して、背景情報を提供しましょう。
2005年頃、私は学校内で入門的なBBSの運用保守をしていました。卒業後は今では斜陽の大手インターネット企業（編注：百度のこと）に入社し、業界横断的なP1レベルの運用保守からスタートしました。 2010年に家出してモバイルインターネットのベンチャー企業に入社しました 当時はシステムのネットワーク配線から計算機室のITまで基本的にやってました 中小企業でもサーバーの調達サイクルが少し長かったのでその際にはクラウドの利用を検討してください。
2011 年以来、私は vmware ベースの Suguang Cloud をしばらく使用してきました。エクスペリエンスは非常に貧弱です。個人的な観点から見ると、使いやすさと経済性は良くありません。唯一のことは、 IDC よりもマシンのインストールが速い場合があります。それからネットワークもおかしくなり、多くのトラブルが発生します。同時に、Shanda Cloud も一時期使用していましたが、Sugon よりも優れたエクスペリエンスでしたが、実質的には VPS レベルでした。 vpc層ができていない感じです。あまり重要なリソースはあえて配置せず、何度もプルした後、使用をやめました (おそらく、正しい方法で使用しておらず、監視するのが簡単ではなかったためです)。
私は 2013 年に ucloud を使い始めました。これは主に仮想マシンを使用し、他にはあまり使用しません。しかし、vpc 製品はその時点で利用可能になっているはずであり、いくつかの重要なビジネスは繰り上げられていたはずです。
2014年に海外ビジネスを始めたためAWSを使い始めました。 2019 年に、すべての IDC ビジネスがクラウドに移行されました。
私が初めて Wang 氏にお会いしたのは、WeChat グループでのディスカッションがきっかけでした。Wang 氏は 4 つのクラウド ネイティブ アプリケーションの実践方法を提案し、これら 4 つが実現されていればよいと信じていました。が実装されており、アプリケーションは基本的にクラウドネイティブです。グループメンバーも深く同意し、「Wang Si Tiao」と名付けました。Wang ボスは、SRETalk 読者に「Wang Si Tiao」のエッセンスを共有していただけますか?
クラウド ネイティブの 4 人の王の詳細バージョンをスウェーデンの Ma Gong リポジトリ (https://github.com/lipingtababa/cloud-native-best-practices) に掲載しました。皆さんの問題提起を歓迎します。クラウド ネイティブの 4 つの王様も随時更新します。
簡単なバージョンは次のとおりです:
編集者注: この簡易版には内容があまりないようですが、実際には多くの内容が含まれています。ぜひ読んでみてください。リンクをクリックできない場合は、「Cloud Native King Si Tiao」 "、上記のリポジトリに移動し、クラウド ネイティブを探します。Wang Si Tiao.md で十分です。
「四天王」には研究開発の協力が必要なベストプラクティスがいくつか挙げられていますが、社内で導入する際に障害は発生しないでしょうか？どうやって解決しましたか？
障害にはほとんど遭遇しませんでしたが、それはお互いの事情があったからです。
一方で、クラウドに移行する以外に選択肢はなく、コスト管理は困難な目標であったため、他に選択できる宥和的なルートはありませんでした。
当社はチームから独立した新しい会社なので、移行には 1 年しか与えられていません。経営陣から与えられた目標は、既存の数千台のマシンをスムーズに稼働させることです。収益性の高いビジネスシームレスに移行されます。当時は海外事業のみを行っていたため、非クラウドソリューションは全く検討していませんでしたが、それでも経営陣からは、これまでIDCを利用するよりもクラウドコストが低いことが求められていました。
元のアーキテクチャを直接クラウドに移行した場合、経営陣が設定したコスト目標は確実に達成できません (この豚舎のボス Feng は、クラウドに対する従来の IDC の見解を支持するために同様の記事を多数書いています。コストの優位性）、その時点では選択肢は 1 つしかありませんでした。それは、移行後にコスト、パフォーマンス、安定性の目標を達成できるように、既存のアーキテクチャを変革してクラウドに適応させることです。
一方で、研究開発がモデルの選択とコストの最適化に全面的に参加することで、全員が合意に達することができます。
私はパブリック クラウドの選定に 1 年ほど前から取り組み、具体的にはクラウドの使い方を学ぶためのトレーニングに参加し、徐々に自分なりの方法論を形成してきました。移行前に、私は研究開発の主要メンバーを関連トレーニングに参加するよう指導しました。トレーニング後、彼らは私の実践の多くが正しかったことを理解することができました。さらに、実際の移行中、AWS はより専門的なソリューションも提供しましたデザイン。したがって、「四天王」の内容を実装するのは比較的簡単です。例:
1. EBS にデータを保存すると非常にコストがかかるため、S3 にデータを保存することは非常に経済的な選択です。さまざまなソリューションのトレーニングと比較により、R&D はこの状況を非常に明確にしたため、プログラムを変更する意欲がさらに高まるでしょう。
2, AWS SDK がロールを非常によくサポートしているため、ロールはセキュリティ要件です。最初に開始するときは、ロールを使用するか ak sk を使用するかに難しさの違いはありません。最初から制御してください。研究開発に関する事項についての質問です。
3. ホスティング サービスに関しては、R&D は運用保守や既存サービスの利用などは実は気にしていません。執着心を捨てて運用・保守ができればそれで十分です。
4. データはサーバーに保存しないでください。実際、私たちは比較的大きな慣らし運転を経験しました。
今回の移行は、完全なプラットフォーム サポートを備えた IDC 環境から AWS への移行です。AWS パートナーの支援により、新しいアーキテクチャは AWS のベスト プラクティスに従って設計され、以前の使用習慣と要件を満たしています。
しかし、再構築のため、使用方法にはまだ違いがあります。 ASG が使用されているため、サーバーは縮小または障害移行中に直接強制終了されます。永続的なデータをサーバーに保存する必要がある場合、そのサーバーは失われます。そのため、この時間が経過すると、R&D は基本的に、オンライン ビジネス データがサーバー上に存在しないことを受け入れることができます。サーバ。
この設計により、サーバー ストレージの要件を可能な限り小さくすることができ、100G を超える場合は私の承認が必要になります。 EBS コストを大幅に節約
その後、研究開発チームが K8S を導入する際に、このことについてより深く理解しましたが、結局のところ、コンテナ内のデータは失われます。
最近、ROR の父や Mr. の記事など、ROI を総合的に測定し、クラウドに移行するほうが費用対効果が高いと考えているという記事がいくつかあります。 . 運用とメンテナンス Baijia フォーラムの前回号の Tuyou Game の Zou さんは、クラウドをより深く使用する傾向があるようです。皆さんと意見を共有できますか?
私は実際に「ベスト プラクティス」を提唱してきましたが、「ベスト プラクティスは投資家または経営者の皇帝の芸術である」とも皆さんに伝えてきました。ベスト プラクティスを使用する可能性は非常に高いです。最適を達成するには自分や他の多くの人の仕事を犠牲にしなければならないということを、自分の仕事を壊さずに最適を達成できれば、選択肢はより多様になります。
クラウドに移行するか、それともクラウドに移行するかは、お客様の関心、管理サポートの強さ、および過去の課題によって異なります。私が鄒さんやDHHの立場だったら、今の考えに固執しないかもしれません。クラウドにこだわり続けることができる:
一方で、それは経営者の認識です。経営者は遊休資産の損失に苦しんでいます。私は長い間、IDC の遊休リソースの最適化を行ってきました。 , そこで海外の自作を追加しました コンピューター室も特に簡単ではありません. 基本的にクラウドに行くことが経営者によってサポートされる唯一の解決策です。 一方で、前述したように、偶然にもアーキテクチャを全面的に変革し、その変革コストを経営陣がサポートしてくれるため、クラウドのメリットを最大限に活かすことができています。最後に、私たちのビジネス モデルには、長期的に安定した高負荷でステートレスなビジネスがまだありません。この種のビジネスは、従来の IDC の方が適しています。
Zou 氏や DHH が既存システムのアーキテクチャを変更するコストは高すぎると思います。たとえ運用保守部門の人件費を削減できたとしても、それを実現するのは難しいかもしれません。これには依然として他の部門の利益が関与しているためです。
しかし、新しい会社や新しいプロジェクトの場合、クラウドほど適切なシナリオはないと考えています。適切なクラウド ベンダーを選択し、クラウド ネイティブ アーキテクチャを使用してビジネスを実装することで、全体のビジネスはパフォーマンスとコストの面で改善でき、弾力性があります。
多くの友人が、クラウドによる豚の殺害やロックなどについて不満を述べていました。しかし、投資家や経営者の視点から見ると、人・クラウド・IDCはすべて事業収益を実現するための要素であり、投資家が事業を実現したいのであれば、これらの要素にお金を払うだけでなく、ニーズを満たす要素をタイムリーに入手します (こちらの方が重要です)。クラウドの要素を入手するのはこれほど簡単ではありません。製品の品質と価格は比較的標準的です。数回クリックするだけで支払いができます。オンデマンドで支払うこともできますが、いつでも使用を停止できます。しかし、人々はどうでしょうか？人材の確保が難しく、質の見極めが難しい 規格化されておらず、価格変動（昇給）がある 安易に人員削減ができず、絶対的な人材に置き換えられない仕事を辞めるときも同様。人間は非常に創造的ですが、標準化や機械的な退屈なことに関しては、SaaS サービスはもちろんのこと、人間は機械の敵になることはできません。
Zou 氏の状況に関して言えば、ビジネス チームがプログラム アーキテクチャの変革に消極的である場合、彼の現在の選択はベスト プラクティスです。安定した高負荷のビジネスの場合は、コスト面で有利な IDC を選択し、マシンを購入するのではなくレンタルし、ビジネスをクラウドに柔軟に移行します。
37signals の Basecamp の場合、製品の価格モデル設定により、クラウドへの移行が少し面倒であると判断されます。現在、ほとんどのSaaSサービスは使用量やユーザー数に応じて料金が支払われるが、Basecampは主に月額わずか199ドルの無制限パッケージを販売している。この価格設定モデルは、クラウドの弾力性を十分に活用して利益を上げることができず、低価格のリソースをオーバーブッキングすることしかできないことを意味します。この価格モデルが変更されない場合、アーキテクチャがどのように最適化されても、クラウドには適さない可能性があります。
最近「運用保守の未来はプラットフォームエンジニアリングである」という記事がありましたが、この見解に同意しますか?プラットフォーム エンジニアリングにおいて、チームにはどのような役割と境界がありますか?いわゆるプラットフォーム エンジニアリング (特にマルチクラウド環境) についてはどのように計画していますか?
これは Ruan Yifeng または Charity Majors によって書かれたものですか?しかし、私はこれら 2 つの記事をこれまで読んだことがなく、ざっと見ただけです。私はこれに全面的に同意するわけではありませんし、個人的には社内プラットフォーム エンジニアリングを行おうとは思いません。
まず最初に、私が同意できない点について話しましょう。その記事には概念についていくつかの誤解があります。
まず、DevOps は立場ではありません。私は長い間それを理解しようと努めてきましたが、最終的に感じたのは、DevOps は開発モデルであるということです。ただし、この開発モデルの中核は研究開発であり、すべての要素が効率的な研究開発反復サービスに焦点を当てる必要があります。記事では、当初は DevOps がポジションであると考えていましたが、その後、このポジションはビジネス開発のためのものであると信じられていましたが、これらは不適切な理解だと思います。
第二に、運用と保守には将来検討すべきことがたくさんあります。変革は新しいトピックではありません。運用保守業界が斜陽産業であることは長い間誰もが理解していました。過去 10 年ほどで、多くの運用保守業界が変革を図り、次のステップへの活路を見つけようとしています。 CI/CDをやろうとしている人、CI/CDをやろうとしている人、監視の研究開発をやろうとしている人、運用保守の自動化基盤を開発しようとしている人、新しい分野に挑戦しようとしている人（ K8s、ビッグ データ、AI、クラウド コンピューティングなど)、他のサブプロジェクト (DBA、ネットワーク セキュリティなど) に移行しようとしているプロジェクトもあります。
これらの変換の多くは DevOps 開発モデルに役立つことがわかります。
プラットフォームエンジニアリングは実装モデルかもしれませんが、運用保守グループの製品力や研究開発レベルを考えると、プラットフォームエンジニアリングを自分でやるのは面白がってやるしかなく、安定性すら保証できないのではないかと心配しています。保証されても負担が増えるだけです。しかし、より専門的な制作・研究チームを導入してそれを行う場合、一方では、適切に事業を行っておらず、本業の収入に関係のない場合には支援を得ることが難しくなります。 , それは単なる自己利用のためのプラットフォームです. 収入のない製品を作るために多くの人を集めるのは経済的ではありません, そしてサポートを得るのはさらに困難です. さらに、このアプローチには参加意識がありません.既存の運用と保守を維持するものであり、変革とはみなされません。
なので、成熟したプラットフォームやツール(オープンソース/有料自作、SaaS利用可)を利用するのが正解だと思いますので、これらのプラットフォームをベースにカスタマイズや二次開発を行うことも可能ですが、ただし、車輪の再発明はしないでください。
最後に、この記事のプラットフォームに対する私の理解も異なります。
プラットフォーム自体はSaaSで提供できるので二次統合の必要がないのですが、その最大の理由は国内のSaaS環境が整っておらず、ソフトウェアサービスが充実していないことです。相互の統合や互換性には注意を払わず、より大きく成長することを好みます。海外に目を向けてみると、海外にはSaaSやニッチな分野のソフトウェアがたくさんあり、それらは非常に優れていて、他のソフトウェアと統合することができ、エコシステムが非常に優れているので、統合の設定が容易であり、また、統合が容易ではありません。二次開発の負担が大きい。
一方、プラットフォームのユーザーは研究開発者であるべきであり、研究開発者は、プラットフォームを伝達したり承認したりするための運用保守を必要とせずに、プラットフォームを直接使用できる必要があります。
つまり、将来的にはプラットフォームを使用する必要があります。それは、プロの制作チームと研究チームによって作られたプラットフォームであり、自分たちで作ったおもちゃではなく、制作チームと研究チームが使用するプラットフォームです。途中で運用・保守するのではなく、直接、発信者となる。
そのため、プラットフォーム エンジニアリングでは、成熟したソフトウェアまたは SaaS サービスを積極的に使用し、それらをできる限り生産チームや研究チームが直接使用できるように提供することを選択します。
運用とメンテナンスでは、コストとセキュリティに基づいて必要なチェックポイントのみを作成し、ポリシー、権限、監査を通じてチェックポイントを制御して、運用チームと研究チームがそれらを正しく使用できるようにします。
王社長の働き方モデルでは、非常に上級の人材だけが必要だと感じています。研究開発コーチの役割を担うには新鮮な血は若すぎますが、新鮮な血がなければ務まりません。ウェイジさん、どのようにして組織を構築しているか教えていただけますか?
私もまだ解決していないので、これは良い質問です。この作業モデルではこれは問題ではありません。
多くの企業やさまざまな職種がシニア人材を求めており、それらはすべて私が現在抱えている同じ問題に直面しています。上級人材を必要としない仕事は何ですか?仕事内容は非常に標準化されており、会社からの要求も高くなく、誰でもニーズに合わせて明確な指示を出してうまく仕事ができると思います。機械でもできますよ。
鄒氏は、「従来の運用保守は掃除に似ている。仕事の内容は重要だが価値は高くない」と語ります。私もこの意見に非常に同感であり、これが私たちが今、運用・保守現場で直面しているジレンマです。では、清掃チームは独自の清掃ツールを開発するのでしょうか、それとも購入するのでしょうか?
成熟した製品や外部サービスを多数使用しているため、さまざまな自動および半自動清掃ツールを使用した清掃と同様に、より安定して清掃タスクを出力できます。しかし、その人の清掃能力の欠如によってモップがけが不潔になったり、プロ意識の欠如によって単純なスキャンだけで仕事が引き渡されたりすることを心配する必要はありません。クリーニングには、これらのツールを従来のツールよりもうまく操作するためにもう少し学習と困難が必要ですが、成熟したツールが詳細を保護するため、全体的な SOP は以前よりも低くなります。
したがって、価値の低い作業内容に時間を無駄にするべきではありません。この種の作業は、スケールメリットがあり、優れた機能と SLA を備えたプロフェッショナル ソフトウェアまたは SaaS で完了する必要があります。私たちは、企業、経営者、投資家がより懸念している分野に重点を置く必要があります。
王社長は常に「運用保守の自己革命」、つまり「反人間的」な考え方を提唱していると思いますが、その背景にある考え方についてお話しいただけますか?
現在私たちが目にしている事実は、運用保守は急成長している業界ではないということです。ほとんどの企業には、企業のシステムの運用をサポートする大規模な運用保守部門がありません。必要な担当者は 1 人だけで、IT、ネットワーク管理、セキュリティ、その他のタスクも担当します。 「改善の余地はありません。維持管理責任者は非常に少なく、基本的には維持管理責任者が限界です。今私が管理している人数では、私を維持管理責任者と呼んでもいいでしょう。」
現在、業界も同様の状況で、多数のトレーニングコースが迅速な運用とメンテナンスを提供しており、十分かつ安価です。ミッドエンドからハイエンドの運用と保守はほとんどありません。運用と保守は、ネットワーク エンジニアや DBA とは異なります。当社のテクノロジー スタックは非常に複雑であり、当社の能力を示す権威ある認定はありません。これは当社の計画に役立ちません。キャリアパスと健全な人材の形成市場。したがって、当社の運用保守に対する市場の位置づけは、実は雑務であり、「ビジネスコードを書かないあの技術」が最も正確な位置づけなのかもしれません。
DevOps の概念によれば、生産や研究に混乱をもたらすのではなく、ビジネスの提供を迅速化し、優れたサービスを提供する必要があります。しかし、運用保守の意味や仕事はDevOpsに限った話ではなく、ここが他の多くの人と私の考えが異なる点です。
一方で、運用と保守は企業のデジタル資産の「番犬」であり、この観点から見ると、運用と保守は経営陣と投資家の利益を代表し、企業のデジタル資産を適切に保護し、デジタル資産を確実に保護します。正しく使用でき、さまざまな規制要件を満たし、さまざまな内部監査に参加できます。それは、生産および研究チームに対する経営陣のチェックアンドバランスです。実はこれが初期運用保守の意味なのです。
一方、この国は食べ物を高く評価しています。規制要件はますます厳しくなり、ネットワークセキュリティ、データセキュリティ、個人情報保護のいずれにおいても、関連業務を担当する専任の担当者が求められています。小規模企業の場合、これらのタスクは運用と保守、特にデータセキュリティによって同時に実行する必要があり、デジタル資産を直接担当する担当者が関与する必要があります。それが新しい時代の運用・保守に求められるものです。
したがって、これを理解したい場合は、Devop とプラットフォームはすべて、運用保守作業のほんの一部であることがわかります。私たちはこれらのしがらみから自分自身を解放し、自分自身を解きほぐし、生産と研究を行う必要があります。チームはバラバラであり、管理と監督の観点で良い仕事をしています。
以上が自己革命の「四天王」を実践する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
