1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

HolmesAdvent Calendar 2020

Day 19

DevOpsに本気で取り組んだ1年の振り返り

Last updated at Posted at 2020-12-20

これは、Holmes Advent Calendar 2020の19日目の記事です。

こんにちは。株式会社Holmesで取締役CTOをやっている花井です。
年末ということもあり、1年間のDevOpsの取り組みを振り返り、その一部を紹介したいと思います。

はじめに

DevOpsがビジネス価値をもたらすことは、State of DevOps Report 2020等で示されており、このHighパフォーマーの尻尾を掴むためにまずは1weekサイクルで本番環境へのデプロイができる状態を目指しました。
DevOpsプラクティスを取り入れている組織とそうでない組織を比べると以下の成績に大きな違いがあり、単に開発工程のベストプラクティスとしての取り組みではなく、ある時点のビジネス成果を同じとした場合により早く辿り着くことができる長期的な速さを得られるものと捉えています。

  • 本番デプロイの成功率
  • 生産性、マーケットシェア、利益性の目標達成率
  • サービスを復元するためにかかる平均時間

一般的に言われるようなDevとOpsの対立関係については一つの組織としてまとまり、組織目標の作り方によって打ち消しているため、元々(把握している限り)存在しておらず、これを解消したいという動機は一切ありません。

バッチサイズの縮小

従来は、当然の事ながらバッチサイズに比例してデプロイ成功率が下がる傾向である事が課題でした。そのため、バッチサイズを一定にする事をマストとして、コードやインフラを変更する事による影響のチェックを定型化してノウハウを獲得し、一定のリズムで一定の検査が出来る状態を目指す中で、イレギュラーケースやプロセスの問題を炙り出して改善するアプローチを取りました。
バッチサイズを一定とするためにはフィーチャートグルによってコントロールをする必要があり、作りかけの機能を構成するコードは本番環境にデリバリーされても表面化しないようトグルをOFFにして無害化しておく仕掛けを組み入れます。そのためには、トグルを意識した開発と環境毎の切り分けをする必要があり多少の非効率さはあるものの、それと引き換えに余りある成果が得られると思えば払うべきコストだし、実際のところ顕著なスピードダウンはパフォーマンス指標上も見られず比較的スムーズに導入できたと思います。
分かっていた事とはいえ、プロセスが安定してリズムに乗るまで、様々な問題が浮上しては潰してを繰り返す間は度々混乱もあり高コストだったと思います。

パイプラインの統合

元々コードの各環境へのデプロイはパイプラインに統合されてビルドとユニットテストの実行といった、最小限の継続的デリバリーは自動化していました。
これに加えてコードの静的解析と一部のパフォーマンステストについてはパイプラインに組み込み、セキュリティチェックやリグレッションテストはマニュアルオペレーションでのベストプラクティスを探るため、敢えて自動化から入らないアプローチを取りました。これは、E2Eテストが手負いとなって短サイクルで回す中でテストを通すことが目的となってしまい欠陥を検出する本来の目的を果たせなくなる可能性と、全体的なUIリニューアルを行っているプロジェクト状況からせっかく作ったテストコードの賞味期限が短い事も理由の一つです。

パフォーマンスの計測

上半期で2week、下半期で1weekまでサイクルを縮めるため、上半期はシンプルにデプロイ回数を指標として下半期はAgileプロセスのパフォーマンスと合わせる形で提供価値のある機能単位でのOn-time delivery率をパフォーマンス計測の指標としました。
それと同時に品質が犠牲になっていないことを確認するため欠陥検出率を指標として併せ持ち、結果として小さいバッチサイズで検査をして頻繁に本番環境へのデプロイをする方が品質はむしろ上がる事を検証しようとしました。
価値を早く安全に届ける共通目的の元で、テストケースやコード変更による影響範囲を特定し易くし、範囲を絞った検査と如何なる時も実施する重要シナリオテストによって検出された欠陥を修正して再提出するといった、健全なDevとOpsへの受け渡しがされるようになったと思います。

まとめ

紹介した他にも受け渡し制限やGit戦略などの施策を合わせ、QAチームに足を向けて寝られない中でDevOpsに本気で取り組んだ結果、1weekサイクルのデプロイを実現する事ができ、同時にボトルネックとなりがちなプロセスを特定して新たな課題を発見することもできました。
この先マニュアル運用の成熟を求めるとMid/Low-level寄りのアプローチでより変更が難しくなりバッチサイズが大きくなるループから抜け出せなくなるため、エンジニアリング駆動での自動化を目指す方向になると思います。
また、期待するようなビジネス成果を得るためにはビルドトラップに陥らずフィードバックループを獲得する必要があり、ずっとフィーチャートグルをかけた状態でデプロイ成功率だけ高めていても仕方なく、顧客に価値を届けるまでを1サイクルと捉えて全体適用する必要があり、下半期はBiz+DevOpsを取り組むテーマとして追加しました。
うまく動いているものは触らないの原則に引っ張られそうになりながらも理想の状態に近づけるための必要なリスクは取り、今後もスピードと品質をトレードオフせず両立するために組織的な学習と改善、安全尊重の文化を醸成していきたいと思います。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?