序文
年末になり、友達を解散していない人はすぐに分裂します。いわゆる新年は新しく、毎年同じことが繰り返されることはありません。
意図せずに行って滞在し、残りの雲を見てください。。。運用・保守は消えませんが、シフトします。
噂
1クラウドネイティブとは何ですか？
最近、クラウドネイティブが人気になり、あらゆる種類の問題が発生しましたが、クラウドネイティブとは正確には何ですか？クラウドネイティブ以外のすべてはワイルドですか？
クラウドネイティブの元の名前はクラウドネイティブです。つまり、このプログラムはクラウドのカスタマイズ用に開発されています。クラウドネイティブの開発はいくつかの段階を経ています。最初の段階は、すべてのiaas、paas、saasを含むコンピューター室で、従来の運用と保守です。 ;第2段階は、IAASの人々を殺すクラウドホスティングの時代です。これは、クラウドコンピューティングの時代でもあります。アプリケーションはクラウドに移行します。現時点では、アプリケーションは基本的にクラウドIAASを使用する製品のみであり、PAASはあまり使用されていません。 ;第3段階はクラウドネイティブの時代です。つまり、IAASを使用するだけでなく、PAASを使用して、アプリケーションに関連するさまざまなクラウド製品を選択します。クラウド上にある限り、サードパーティが持つことができる限り、彼らはそれを自分で構築しません。 、ただ買って買う、あなたは何をしますか？ビジネスに集中するだけです。現時点では、クラウドの力を最大限に活用して、ビジネスの発展と革新を継続できるようにしてください。
第1段階から第2段階までは、プラットフォームを置き換えるために再ホストまたは再プラットフォーム化するだけなので、比較的簡単です。そのため、コンピューター室の運用および保守担当者のみが失業し、クラウドベンダーが恩恵を受けます。第2段階から第3段階まで、これはその際、クラウドを理解し、クラウド製品を理解し、クラウドサービスを理解する必要があるため、アプリケーション開発のしきい値が低くなり、スキルの飛躍が必要になります。専門的な運用と保守がない場合は、運用と保守についてもう少し知る必要があるかもしれません。
この時点で、第2段階から第3段階まで、マイクロサービスを使用してk8sアーキテクチャを使用する必要があります。もちろん、これはインフラストラクチャの一部であり、k8sのしきい値が非常に高いため、k8sを理解する必要はありません。開発は固定されておらず、通常の運用や保守でも手間がかかります。もちろん、この時点でサーバーレスを使用することもできます。そうすれば、クラウドベンダーが基本的なサービスを構築し、軽い運用と保守のモードを採用します。
2なぜクラウドネイティブSREが必要なのですか？
クラウドネイティブ時代では、運用と保守の要件が高くなります。クラウドを理解する必要があります。クラウド製品、クラウドプラットフォーム、クラウドサービス、およびさまざまなスキルのフルスタック開発を理解する必要があります。クラウド製品の選択を理解する必要があります。マイクロサービスのデータリンクを理解するには、k8のスケジューリングを理解する必要があります。また、開発機能を開発し、さまざまなyamlファイルを作成する必要がある場合もあります。。。
これらすべてがクラウドネイティブSREの誕生に貢献しています。クラウドネイティブSREは、プラットフォームレベルの運用と保守に属し、データの運用と保守に属します。これらのSREに頭脳があれば、インテリジェントな運用と保守に変換できます。
ハイエンド製品にはハイエンド成分が含まれている必要があります。これはクラウドネイティブSREの段階です。
クラウドネイティブSREの3つのコア機能
さまざまなマイクロサービス、フロントエンドデータ、中間データ、バックエンドデータ、保存されたデータ、さまざまなデータ、さまざまなAPMのデータベースの運用と保守、データの収集、データの保存、分析データ、使用データ、データサービス。
マイクロサービスはモノリシックアプリケーションとは異なり、より多くのデータを生成します。K8sは、さまざまなデータが生成され、コンテナが動的に破棄される強力なコンテナオーケストレーションシステムです。
運用・保守データを抽出・処理・洗浄し、最終的に一元的に保存してデータ資産を形成し、関連する運用・保守データを分析することで、シーンに応じたさまざまなデータサービスを開発し、大画面の監視画面に表示したり、関係者に見せたりすることができます。次元分析により、リアルタイムのデータフローの視覚化が可能になります。
最も一般的なのは障害情報です。障害が発生すると、SLAの設定、サービス管理、リンク全体の情報の収集と保存を行うために、すべてのデータが収集および沈殿されます。障害情報が一目でわかります。改善策の後、障害を実行できます。データは前後で比較されるため、関連する改善が実際に効果的であるかどうかを確認できます。
関連データにタグを付けることもできるため、関連データに応じて、ログ、pv、または販売など、さまざまな運用および保守シナリオの分析のために関係者にプッシュできます。
リンク全体が開かれ、アプリケーションの開発、テスト、ビジネスの運用と保守、プラットフォームの運用と保守が行われます。各リンクで何が起こっているかを誰もが確認できます。たとえば、バックエンドのマイクロサービスインターフェイスがダウンしている、ビジネス上の損失がいくつ発生したかなどです。中断、より良い改善のために、失敗の影響を全員に知らせてください。
4サーバーレス
いわゆるサーバーレスとは、表面上はサーバーレスを意味します。最初の意味は、serverless = faas + baas、つまり機能コンピューティングとバックエンドサービスです。どちらもapiを使用して呼び出します。現在、さまざまなデジタル変換でもapiが使用されています。電話を掛ける。
サーバーレスを使用すると、開発をビジネスやクラウドベンダーが行うその他のことに集中できますが、実際には、ビジネスの運用と保守のために行う必要があります。これにより、運用と保守が節約されますが、運用と保守がなくなることはありません。
サーバーレスの開発とテストを行う場合は、環境を分離する必要があります。そうしないと、エンドレスループが作成され、サーバーレスの柔軟な支払いは非常に柔軟であるため、仮想マシンを使用するプリペイドモデルとは異なり、すぐに破産する可能性があります。 、クォータを直接制限しますが、サーバーレスを使用する場合は、プリペイドモデルを使用してこの問題を解決することもできますが、自慢するほど柔軟ではありません。サーバーレスのコールドスタート時間は、実際にはプリペイドによって解決されます。 、つまり、通常の流れを解くための予約量、弾力性を利用して山と谷の流れに対応し、柔軟性を最大限に発揮します。
サーバーレスはデバッグ時に非常に便利です。本番環境では非常に便利ですが、パフォーマンステストとストレステストを実行する必要があるため、仮想マシンをテスト環境として使用するのが最善の方法です。サーバーレスを使用すると、コストが大幅に上昇する可能性があります。 。
サーバーレスは、悪意のある攻撃を防ぐときにも厄介です。トラフィックがいっぱいになり、トラフィックが常にピークになるため、コストも高くなるため、セキュリティ製品を購入する必要があります。
サーバーレスは、クラウド製品を選択する際に選択する必要があるため、軽い操作および保守モードを採用します。さまざまな機能マニュアルを読む必要があります。非常に詳細ですが、あらゆる種類のクラウド製品が魅力的であることがわかります。 、ビジネスに集中するのが良いと言うなら、あなたはそれらの悪い文書を読ませる。
サーバーレスは、ハイエンドテクノロジーを使用すると必然的にさまざまなバインディングが生成されるため、技術的な機能も低下します。メーカーのロックインは不可欠なトピックであり、移行する場合、各メーカーが次のような公的な標準を開発しない限り、言うのは難しいです。コンテナ。。。
サーバーレス開発モデルも、元々制御可能だったように、多くの習慣を変えるでしょうが、今ではクラウドベンダーの手に渡っていないことがわかりました。知りたい場合は、基本的にオープンではなく、見ることしかできません。あなた自身のログに。
技術の波に直面して、それは殺されるか何かをすることです。。。
大学が一度失敗するのは完璧ではありません。。。会社では、一度解雇されないことは完璧ではなく、一度PIPされないことは完璧ではなく、一度PUAにならないことも完璧ではありません。。。経験は一種の富であり、経験は自分を信じているからです。