DevOpsはITILと互換性がありますか？

私のキャリアの中で、私はソフトウェア開発者であり、ITILの実務家でもありました。したがって、DevOpsは私にとって自然な進歩でした。
しかし、私は常にITILが導入する高度に専門化された言語と格闘しており、その「開発者に優しい」ことで開発者を完全に引き離さないようにしました。

ITILは、組織の運用の安定性と成熟度に実証済みのメリットをもたらす一連のプラクティスとして30年以上にわたって開発された、国際的に認められたITサービス管理フレームワークです。

DevOpsはITILと完全に互換性がありますか、または本質的にITILの精神を取り入れて、開発チームがより理解しやすい言語に「翻訳」する必要がありますか。

• インシデントおよび問題管理→生産上の欠陥、バグまたは問題
• 変更およびリリース管理→継続的デリバリー
• イベント管理→ロギング、テレメトリ、計装、アラート

私の意見では、DevOps文化はアジャイルプロセス管理に向けた方法論の変更を伴います。
ITILは、プロセスと結果の明確な形式を主眼としているため、ウォーターフォールモデルにより適合しています。

これは、ITILがDevopsと互換性がないことを意味するものではありませんが、通常、これは異なるタイムラインを持つ2つの別個のプロセスになります。ITIL参照に新しい製品を含めることは、通常、製品/アプリケーションが本番環境でしばらくリリースされるまで遅れます。ITILを統合するために必要な初期の落とし穴といくつかのドキュメントは、ライブ"。

ITILの1つは、開発タスクの前に定義されると想定されるサービス設計です。アジャイルプロセスは、各反復で設計をレビューし、ITILプロセスで必要な形式を破ります。

ITILの主な目標は、あなたが言ったように、設計/構想と保守段階（ビルド/実行）の間で何も省略されないことを保証するフレームワークを提供することです。devops文化では、チーム全体が長期にわたるすべての段階を担当するため、形式主義が削減される理由があります。

ITILを忘れる必要があるという意味ではありません。中核となる原則は絶対に良いものであり、私の意見では、製品の初期バックログを作成するためのチェックリストとして使用する必要があります。ITILの原則に従うと、その形式主義はすべて、迅速な反復ソフトウェア開発という市場投入時間の短縮目標に反し、タスクは同じチームによって行われるため、チーム間で必要な情報の伝達が少なくなるため、適用できないこともあります。

私はITILの認定を受けています（しばらくの間）。私はTensibaiに同意します。ITILとDevOpsは非互換ではありませんが、必ずしも素晴らしい友達になるわけではありません。

特に大規模な組織では、ITILのプロセスが何らかの方法で行われなければならないという主張をすることができます。ITILが既に実践されているDevOpsプラクティスの統合を成功させるには、慎重な計画、コミュニケーション、実行が必要です。繰り返しになりますが、これはすべてのDevOps変換に当てはまります。

ITILもDevOpsも使用されていない「グリーンフィールド」変換の場合、説明したように「マップ」用語を使用して両方を組み合わせて作成します。組織内の全員が同じ言語を使用して同じページにいる限り、ITILとDevOpsを組み合わせることで価値を高めることができます。

私はによって提供さ答え好かIT懐疑論上のエピソードのDevOpsCafe.orgを、私はそれを正しく覚えていれば、思考の彼のラインは、あなたが実際に本当にITILを理解していれば、非常に少ない競合があるということです。ITILガイドラインの大部分は非常に一般的であり、競合は主に実際の仕様の背後ではなく、ITILのいくつかの実装間のものであるということです。