自分なりのDevOps思考整理

仕事で聞かれたので長文メールで返したが、個人的にも整理のために、メールを転記してまとめておく。（2017-04-19時点での見解。）

内容

DevOpsに関連した”運用の”具体的な仕組みとツールを示すための参考となる情報
DevOpsの概念

を回答できればと思います。

1.具体的な仕組みとツール

案件、業務、お客さま文化等はあえて意識せず、一般論で列挙します。

アジャイル

「最小のコストで最大の価値を得る。」

純粋なDevOpsをやろうとすると「アジャイル」という開発手法がほぼ必須。
本当に必要なものから、最小限で動くものを作って、徐々に拡張する進め方。
アジャイルで速く作ったものを、次はどう速くリリースするか、がDevOps。
開発方法論の話になるので、細かい説明は省略。

⇒調べる場合は、”アジャイル宣言”、”XP”、”Scrum”、”ユーザーストーリーマッピング”といったキーワードを押さえるとよいと思います。

CI/CD（継続的インテグレーション、継続的デプロイ）

「作ったものは常にテストする。」

必然と、テストしやすい設計になる。　→TDD（テスト駆動開発）
小さい変更毎にコミットする。動かないときの影響がため。→Git/GitHub
テストは自動実行。手作業ではやってられない。→JenkinsからJUnit＋SonarQube
動いたものは試験サーバに自動デプロイ・テスト→Jenkins＋Ansible、Selenium
商用DBを完全再現（重要情報はマスク）してデータ起因のバグもつぶす→Delphix

Infrastracture as Code、リリース、オートスケール

「OS・MW設定もコード管理する。」

仮想OSで即座に開発・試験環境構築。→VirtualBox、Vagrant
インストールや設定はコード化によって作業ミス撲滅。→Ansible、Terraform
サーバ情報はシステム的に一元管理。→Serf、Consul
サーバ状態確認もテストコード化。リグレッションテストも。→Serverspec、Infrataster
コンテナ化でさらに構築スピードアップ。→Docker、OpenShift、Kubernates
サーバ設定の手作業修正は完全NG。→Immutable Infrastructure
本番サーバ複数台に自動デプロイ／エラー時に切り戻し→Ansible＋Capistrano
RDBのDDLもバージョン管理。切り戻しも可能。→Flyway
サービスを止めずにリリース。いわゆる縮退。→Rolling Deploy
完全2面化で無停止リリース。→Blue-Green Deploy
一部の顧客に先行試験的に新機能リリース。A/Bテスト的な。→Canary Release

アプリケーション性能管理（APM）、モニタリング、監視

「稼働状況はリアルタイムで把握。異常は即時検知して即時通知。」

リアルタイムエラー監視。→ZABBIXで監視、Prometheusで可視化。
リアルタイムログ収集。→fluentdで一括収集、Elasticsearch/kibanaで可視化。
アプリケーション性能監視。→NewRelicでボトルネック分析・可視化。
イベント、アラート通知。→Slackで即時通知。緊急リブートもチャットから可能。
障害時自動架電。→Pagerdutyで自動電話連絡。

以上、一言ずつですがポイントとなるツールや仕組みになります。

2.DevOpsの概念

背景

DevOpsは言葉の通りDevとOpsが協力することを表しますが、その背景が重要です。

システムは根本的に、ビジネス的なニーズに合わせて変更するのが必然です。

様々なニーズに合わせて柔軟に変更することで、利益・成果を増やしたい（＝Biz）

これを作るのが開発、動かすのが運用、ここで組織の目的に相反がうまれます。

新しい機能を開発したい、どんどん変更したい（＝Dev）
安定して運用したい、できるだけ変更したくない（＝Ops）

しかし、この相反は本質的ではなく、安定運用しつつも、新しい機能を開発できるはず。

どうすれば可能かを追求する、これがDevOps。※Biz-Dev-Opsとも言う。

目的

DevOpsの目的は、「より早く、より確実に、利用者にサービスを提供すること」。

（Why-What-Howで考えると、協力することはHowであって、Whyは上記。）

前提

また、「Ops」という名前がついてはいますが、あくまで「変更」が前提です。変更されない（変更が少ない）システムに対して、DevOpsを適用しても、かけたコストに見合うリターンは見込めない可能性があります。

例えば、テストを自動化すれば「何かが楽になる」と考えられている場合、それは間違いです。テストを自動化すること自体には、高いスキルとコストがかかります。下手をするとメンテナンスがされなくなり、次第に修正すらできなくなり、高いコストをかけたものがまったく無駄になることも少なくありません。繰り返し実行して初めてコストに見合うだけの成果と品質が得られるものです。