DevOps

一言でいうと

開発と運用の断絶を埋め、変更を安全に速く届けるための取り組みです。ツールの名前ではなく、組織と工程の設計を指します。

提唱者と登場年

2009年が起点です。同年のVelocityカンファレンスでJohn Allspawらが発表した「10+ Deploys Per Day: Dev and Ops Cooperation」に触発されたPatrick Deboisが、ベルギーのGentで最初のDevOpsDaysを開催しました。この会の名前が語として定着します。

出発点が運用側からの問題提起だったことは、いまも語の使われ方に残っています。開発の速度を上げる話としてだけ扱うと、元の問題意識が抜け落ちます。

何を解決するか

開発チームは変更を出したい、運用チームは安定させたい。この対立は、両者の評価指標が分かれている限り構造的に生じます。変更のたびに引き継ぎと調整が挟まり、リリースの間隔が伸び、間隔が伸びるほど一度の変更が大きくなって失敗しやすくなる、という悪循環に入ります。

この循環を断ち切る方向が、変更を小さく頻繁にすることです。技術だけでなく、誰が本番に責任を持つかという分担の問題でもあります。

実際の進み方

自動化と計測が中心になります。ビルドとテストとデプロイを自動化し、本番の状態を計測できるようにしたうえで、変更の頻度、リードタイム、失敗率、復旧時間といった指標で状態を見ます。

組織の側も変えます。運用の責任を開発チームが一部負う、あるいは基盤チームが開発チームの自律性を高める形にするなど、引き継ぎの回数を減らす設計を伴わないと、自動化だけでは循環は切れません。

導入でよくある失敗

• ツールの導入で完了とする。組織の分担が変わらなければリリース間隔は縮みません
• 専任の部署を作って任せる。新しい引き継ぎ先が増えるだけになります
• 速度の指標だけを追う。失敗率と復旧時間を併せて見ないと安定性が落ちます

求人票にこの語がある場合に読み取れること

自動化と運用の改善に投資している組織である可能性が高くなります。ただし、この語が単にインフラ担当の職種名として使われている求人も多くあります。

検索条件としては、DevOpsエンジニアやSREという職種名に翻訳できます。この形なら媒体で引けますが、語そのものを要件に書いても対象は絞れません。

自社側で押さえるのは、リリースの頻度と、本番障害時に誰が対応するかです。当番の頻度、深夜対応の有無、手当の扱いまで確認してください。候補者が面談で必ず聞く項目で、求人票に書けるかどうかで返信率が変わります。候補者には、前職での障害対応の経験を聞きます。

隣接手法との違い

関連キーワード

CI/CD / IaC / SRE / Team Topologies