ビジネスの成功におけるテクノロジーの重要性の高まりにより、事実上すべての企業が有能で経験豊富なITプロフェッショナルを雇うことを余儀なくされています。 テクノロジーエコシステムがますます複雑になるにつれて、組織は製品開発、トラブルシューティング、カスタマーサービスなどのタスクに集中するための幅広い専門家を必要としています。 SREとDevOpsは、成功への最も重要なアプローチのXNUMXつとして浮上しています。 多くの場合、テクノロジーに対してさまざまなアプローチを取りますが、プロセスを合理化できる補完的な役割を果たします。
内容
- SRE（サイト信頼性エンジニアリング）とは何ですか？
- DevOpsとは何ですか？
- DevOpsとSREの最大の違い
- DevOpsとSREの類似点は何ですか？
- SREとDevOpsがどのように連携してより効果的に機能するか（そして機能するか）
- DevOpsとSREの未来
SRE（サイト信頼性エンジニアリング）とは何ですか？
サイト信頼性エンジニアリング（SRE）は、システムを可能な限り信頼できるものにすることに重点を置く傾向があります。 実際には、SREは、特定の一連のタスクを実行するのと同じくらい、テクノロジーに対する哲学的アプローチのように見えることがよくあります。 たとえば、SREは、次のようなシステムの特性と原則を強調しています。
- 反復的なタスクを削減または排除する自動化。
- 設計と 可観測性の実装 システムパフォーマンスを確保するため。
- 容量変更の計画。
- 信頼性の目標を確立して測定します（詳細は以下を参照）。
- インシデント管理プロセスの作成、テスト、および微調整。
- カオスエンジニアリング これにより、システムと製品が限界に達し、予期しないイベントにどのように対応するかがわかります。
- 避けられないリスクを受け入れる。
- 分散システムの監視。
- 可能な限り労力を排除します。
主要な操作と主要業績評価指標（KPI）
SREチームのメンバーは、さまざまな役割を果たすことができます。 ただし、SREで作業するほとんどの人は、次のような主要な操作に重点を置いています。
- カスタマーサポートチームがチケットをエスカレーションするために使用できるソフトウェアを作成する。
- エスカレーションの問題に対処する。
- 計画を通じて成功を確実にするためのデータのキャプチャと測定。
- イベントを文書化するインシデント後のレビューを書く。
SREはデータに依存しているため、明確に定義されたインジケーターが必要です。 最も重要なKPIには、次のものがあります。
- 稼働時間。
- ダウンタイム。
- 可用性。
- 平均故障間隔。
- 解決までの平均時間。
- 応答する平均時間。
SREのSLA、SLI、およびSLOの役割は何ですか
SLA、SLI、およびSLOは、SREで重要な役割を果たします。 簡単な概要として：
- SLA（サービスレベルアグリーメント）は、会社とそのクライアントなどのXNUMXつの当事者間のコミットメントを定義します。
- SLO（サービスレベル目標）は、企業が達成するための目標を設定します。
- SLI（サービスレベルインジケーター）は、実際のメトリックを提供します。
SLAの役割
An SLA 企業が満たそうと努力するコミットメントを設定します。 たとえば、99％のサーバー稼働時間を維持することを会社に要求する契約を結ぶ場合があります。 これは、期待のベースラインを設定するため、SREにとって重要です。 これらの期待は意図したとおりに達成されない可能性がありますが、SREは、会社が期待に応えたかどうか、またはそうすることにどれだけ近づいたかを測定するために、これらのコミットメントを必要とします。
SLOの役割
SLOは、SLAに準拠するために満たす必要のある目標をさらに推進します。 たとえば、SLAに期間セグメントがある場合、会社は99％の稼働時間を維持する必要があることがわかります。 SLOが不足している場合は、SLAを満たしていません。 ただし、SLOは、SLAが満たされている理由と満たされていない理由についてSREに深い洞察を与えることができます。
SLIの役割
SLIは、満たす予定のKPIの代わりに、実際のメトリックを提供します。 上記の例に従うと、会社のサーバーの稼働率が98％であり、契約に違反していることがわかります。 SREはこの問題を調査し、今後の期待に応えるために稼働時間を改善する方法を見つけます。
SREのメリット
SREには、直接的および間接的なメリットが数多くあります。 最も注目に値する直接的なメリットには、次のものがあります。
- タスクを自動化することで精度を向上させます。
- 自動化によるワークロードの削減。
- 開発プロセスの早い段階でバグを特定して削除します。
- 企業文化の向上に貢献します。
- 他の従業員が価値を創造するための時間を解放します。
- より効率的かつ正確に機能するようにシステムとツールを最新化する。
- 期待と結果を比較して、対処が必要な潜在的な問題を特定します。
間接的に、SREはDevOpsや他の専門家の有効性に貢献する多くの作業を行います。 ITインフラストラクチャ、アプリケーション、および機能が計画どおりに機能する場合、誰もが有意義な作業に集中するためのより多くの時間を持てます。
サイト信頼性エンジニアリングは、主に運用上の問題の解決を扱います。 専門家は、問題を特定して迅速に解決するのに役立つ多様なスキルを持っています。 彼らの仕事をすることによって、彼らは会社のあらゆる側面をより良く働かせます。
DevOpsとは何ですか？
SREは運用開発に重点を置いていますが、DevOpsは開発チームの改善と大胆不敵な展開の実現に重点を置いています。 チームは通常、アプリケーションのより良いバージョンにますますつながる継続的な反復プロセスを使用します。 継続的な反復プロセスは、製品の構築に向けて一歩を踏み出します。 次に、チームは作業のレビューとテストを停止します。 彼らは他の開発者からのフィードバックを要求するかもしれません。 次に、DevOpsチームのメンバーは、学んだことを使用して製品を改善し、さらに一歩前進します。 このプロセスは、製品をリリースする準備ができるまで続きます。
アプリケーションがデプロイされると、DevOpsの作業は終了しません。 また、製品を監視し、バグを特定し、バグを修正してカスタマーエクスペリエンスを向上させる必要があります。
主要な運用とKPI
DevOpsチームが期待する必要のある主要なパフォーマンスメトリックには、次のものがあります。
- 音量を変更する —変更量は、チームが反復間で変更する必要のあるコードの量を測定します。 バージョン間で変更されたコードと静的コードの量を比較することで、このメトリックを取得できます。
- 展開時間 —変更が承認されると、DevOpsチームはそれらをロールアウトできます。 展開時間は、承認された変更を実装するのにかかる時間を測定します。
- 展開頻度 —展開頻度は、チームが更新をリリースする頻度を表します。 ほとんどの場合、組織は、アプリケーションを毎週または隔週で更新するなど、安定したスケジュールを好みます。 ただし、予期しないイベントにより、DevOpsは追加の変更をデプロイする必要があります。
- 故障率の変更 —変更の失敗率をできるだけ低くしたい。 よくできたコードと堅牢なITインフラストラクチャは、その目標を達成するのに役立ちます。 ただし、変更の失敗率を監視すると、DevOpsが問題を特定して解決するのに役立ちます。
- 失敗した展開率 —展開により、停止やその他の問題が発生する可能性があります。 失敗した展開率は、アプリケーションの更新時にこれらの問題が発生する頻度を示します。
- 検出までの時間 —検出までの時間は、DevOpsが問題に気付くまでにかかる時間を測定します。 タスクはキューで待機しているため、検出時間が長くなるとボトルネックが発生する傾向があるため、できるだけ短くする必要があります。
- 回復までの平均時間 —予期しない問題が発生します。 回復までの短い平均時間は、DevOpsチームが問題を迅速に特定して解決する方法を知っていることを示しています。
- SLAコンプライアンス — SLAコンプライアンスは、企業が罰金を回避し、ブランドの評判を高めるのに役立ちます。 コンプライアンス率が低いと、すぐにクライアントが失われる可能性があります。
- 商品在庫 —完璧な世界では、DevOpsは100％の可用性を提供できます。 実際には、通常、何かがそのような高い目標の邪魔になります。 期待を管理し、サービス契約を遵守するために、99％などの現実的な可用性の目標を設定します。
組織が追跡する特定のDevOpsKPIは、作成する製品と従う手順によって異なります。 ただし、多くの場合、上記の指標により、DevOpsチームがその仕事をうまく遂行し、正しい方向に進んでいるかどうかを判断できます。
CI / CD（継続的インテグレーション/継続的デリバリー）：説明
としても知られています CI / CDパイプライン、継続的インテグレーション/継続的デリバリーは、迅速で頻繁なコード変更に焦点を当てたコーディング哲学です。
テクノロジーエコシステムがより多様化するにつれて、この哲学の継続的インテグレーションの側面が必要になりました。 特定のオペレーティングシステムまたはデバイス向けの製品を構築したいと考えている企業はほとんどありません。 代わりに、Android、iOS、macOS、Windowsを使用するデバイスなど、幅広いデバイスと統合できるように、製品を継続的に変更したいと考えています。 ハードウェアおよびOS開発者は製品を頻繁に更新するため、DevOpsが戦略に従うことは理にかなっています。 そうしないと、製品が現代のユーザーにとって時代遅れになる可能性があります。
継続的デリバリーとは、企業が製品を更新するために頼らなければならない頻繁な展開を指します。 DevOpsは、CI / CDでアジャイルな考え方を採用しています。これには、開発の小さなループと一定の増分値が含まれます。 各ループにはコアフェーズ（設計、開発、テスト、配信）がありますが、顧客とのやり取りは一定です。
CI / CDには、可能な限り多くの自動化を含める必要があります。 継続的テストには、回帰とパフォーマンスの自動テストを含めることができます。 非効率またはバグが発生した場合、一部の更新は自動的に展開される可能性があります。 特に問題の原因が明確でなく、創造的な解決策が必要な場合は、人間の介入が必要なものもあります。
CI / CDは、複数の環境に提供したい製品を使用している企業に最適です。主な利点のXNUMXつは、アプリケーションとエクスペリエンスを向上させるために、顧客のフィードバックと対話に重点を置いていることです。 ただし、企業が社内で使用するアプリケーションを作成する場合など、これが常に最も効率的なソリューションであるとは限りません。 アプリにアクセスするほとんどの人が同じオペレーティングシステムを使用しているため、DevOpsはデバイス間のパフォーマンスの問題についてそれほど心配する必要はありません。
DevOpsの利点
- 自動化、継続的配信、およびユーザーフィードバックのサイクルに基づいて構築されたより速い配信時間。
- 製品の安定性を確保するのに役立つ、より頻繁な更新。
- チーム間のコラボレーションが強化され、より深い洞察とより成功した製品開発につながります。
- 自動化されたタスクにより、開発者は実験と革新に時間をかけることができます。
- ユーザーエクスペリエンスとカスタマーエクスペリエンスの向上。
- チームと部門間のサイロを削減する（理想的には排除する）。
- 管理および保守コストの削減。
DevOpsとSREの最大の違い
明らかに、DevOpsとSREの間にはいくつかの重複があります。 いくつかの哲学的および実用的な境界は、XNUMXつの概念を分離します。
SREは理解を通じて失敗を減らしたい
上で説明したように、SREはSLIとSLOに依存して成功と失敗のレベルを測定します。 ただし、測定は、企業が目標を達成するのを妨げる問題を特定して理解するための最初のステップにすぎません。 DevOpsは中断の直接の原因を探す可能性がありますが、SREは、障害の根本的な原因を理解するために、より深く掘り下げたいと考えています。 そうすることで、将来の問題を防ぎ、コストを可能な限り低く抑えることができます。
SREはイベントに関するより多くのデータを収集する傾向があります
DevOpsとSREは、目標を達成するためにデータを必要としています。 ただし、DevOpsは実用的なアプローチを採用しており、多くの場合、差し迫った問題を解決するのに十分な情報を確認することを意味します。 DevOpsの観点からは、常により多くの問題が発生するため、考えるのではなく、今日の問題に焦点を当てることが理にかなっています。 過度に 未来について。
SREは、イベントについてできるだけ多くのデータを必要としています。 今日の問題にパッチを適用することは重要ですが、プロセスはそれだけではありません。 SREはより多くの情報を収集および分析するため、将来の問題を特定するために将来を見据えることができます。 潜在的な問題を解決することで、低コストで効率を向上させる機会が生まれます。
SREとDevOpsはユニファイドコミュニケーションに対して異なるアプローチを採用しています
DevOpsは、サイロを削減することが、部門、チーム、および個人間のコミュニケーションを改善するための最も効果的な方法であると考えています。 すべてのチームが会社のビジョンに沿っていることを望んでいるため、特定の専門家が独自に意思決定を行うのではなく、すべての人が適切な知識にアクセスできるようになります。
SREは、企業のサイロの数を心配することはめったにありませんが、結果としてサイロの数が減ることがよくあります。 代わりに、SREは、組織内のすべての人が同じツールを使用し、統一された慣行に従うことを望んでいます。 その結果、誰もが組織の技術の所有権を取得します。 共有された所有権は、理想的には共有された情報と責任につながります。
DevOpsとSREの類似点は何ですか？
DevOpsとSREは問題を解決するために異なるアプローチを取りますが、最終的にはいくつかの目標を共有します。 DevOpsとSREのいくつかの重要な類似点には、以下に焦点が当てられています。
- 増分変更を使用してすばやく移動します。
- チームと部門間のサイロを削減します。
- 可能な場合は自動化を利用します。
- ネットワークとアプリケーションのパフォーマンスを監視して、問題を特定し、製品を改善します。
全体として、DevOpsとSREは、デジタル制作をより効果的かつ効率的にしたいと考えています。 主な違いは、DevOpsは通常、差し迫った問題を解決するための実用的なアプローチを採用しているのに対し、SREは根本的な問題と将来それらを回避する方法を探求するためにさらに深く掘り下げていることです。
SREとDevOpsがどのように連携してより効果的に機能するか（そして機能するか）
CIOやその他の意思決定者は、SREとDevOpsのどちらかを選択する必要がないことを知っておく必要があります。 多くの場合、これらのアプローチは互いに補完し合って、成功するソリューションを見つけ、全体的なパフォーマンスを向上させることができます。
SREチームとDevOpsチーム間の重なりは、展開、SLAの設定、および予期しない問題の修正中に最も明らかになることがよくあります。
デプロイメント
新製品の展開は、通常、細部に取り組むために費やされた数か月の集大成を表しています。 ユーザーが満足できない製品を展開したいと考える企業はありません。 DevOpsとSREは連携して、このような災害を防ぎます。
DevOpsは、製品の信頼性に貢献するローリングデプロイメントを好みます。 製品スイート全体を顧客に提供する代わりに、DevOpsは新機能をリリースし、バグが発生したときに修正します。 同時に、SREは展開中のほぼすべてのイベントを測定します。 ユーザーはアクセスできなくなりましたか？ もしそうなら、どのくらいの期間ですか？ より多くのユーザーがそれを採用するにつれて、製品は遅くなりましたか？
ローリングデプロイメント中にこの情報を収集すると、DevOpsにフィードバックされ、修正すべき問題がチームに通知されます。
SLAの設定
ほとんどの人はSLAをSREに関連付けます。 SREがDevOpsよりもはるかに頻繁にSLAと連携することは事実ですが、SREはSLAのパフォーマンスを確立および監視するためにDevOpsからの情報に依存することがよくあります。
DevOpsがSREに情報を提供するとき、企業は、満たすことができる合意があり、義務を果たし続けるためにあらゆる変更に適応できることを保証することに取り組むことができます。 両方のチーム間を移動する情報の流れを見たいと考えています。
予期しない問題の修正
最終的に、すべての開発チームが予期しない問題に遭遇します。 それらを見たくはありませんが、DevOpsとSREが解決策を見つけるための新しい機会を生み出します。 ほとんどの場合、DevOpsは問題にパッチを適用し、ユーザーを満足させるための迅速な方法を見つけるでしょう。 一方、SREは問題を詳しく調べて、根本的な原因を特定し、将来の混乱を回避するための計画を立てることができます。
DevOpsとSREの未来
企業はこれまで以上にデジタル製品に依存しているため、DevOpsとSREの継続的なサポートが必要になります。 XNUMXつのチームは別々のままである可能性が高いようです。 ただし、DevOpsとSREの間のコラボレーションと信頼性が高まることが期待できます。 彼らがいくつかの重複を共有していることを認識することは、彼らの努力をより実りあるものにするだけです。 ただし、それらを分離しておくことは、より効率的なソリューションにつながるさまざまな視点を提供することにより、企業に役立ちます。