コンテンツにスキップ

DevOps

DevOpsの定義

Development（開発） + Operation（運用）

Dev 開発サイド（開発者、デザイナー、品質保証等）
Ops 運用サイド（システム管理者、ネットワーク管理者、データベース管理者等）

設計から開発のプロセスや本番サポートまで、サービスライフサイクルのあらゆる段階に運用と開発の技術者が共同で参加する手法

コーディング、テスト、デプロイ、運用が別々のチームで行うのではない

運用と開発のフローをそろえて、ソースコントロールに登録し、テストを組み込む

DevOps導入のメリット

  • 更新頻度の増加
  • リードタイムの短縮
  • 故障件数の削減
  • 障害からの復旧速度の向上
  • 開発者体験の向上

CAMSモデル

  • Cultrue（組織文化）
  • Automation（自動化）
  • Measurement（測定）
  • Sharing（共有）

測定するもの
平均復旧時間（MTTR）、サイクルタイム、コスト、収入、従業員満足度

一般的な手法

1.優先順位

優先順位は、人 > プロセス > ツール

2.継続的デリバリー

開発→テスト→リリースを少しずつ頻繁に行って品質とスピードを高めていく

3.リーンマネジメント

  • 作業を細分化する
  • WIP（やりかけの作業）を制限する
  • フィードバックループを設ける
  • 可視化を行う

※ WIP（Work In Progress）
WIP制限は、アジャイル開発やプロジェクト管理において、同時に進行中の作業（WIP）の数に制限を設けることを指す。具体的には、1人または1チームが同時に着手できる作業量を制限することで、タスクの切り替えによる無駄を省き、1つの作業サイクルに集中してタスクを早く完了させることが狙い。

4.変更管理

  • 脆弱なアーティファクトの削減
  • 繰り返し可能なビルドプロセスの作成
  • 依存関係の整理
  • 継続的な改良の環境づくり

5.Infrastructure as Code

  • システムをコードのように運用管理する
  • ソースコントロールに登録する
  • ビルドや自動テストでコードレビューを行う
  • コードを実行することでシステムを構築、管理する

DevOpsの実践法

  • インシデントコマンドシステム（消防署を参考）
  • オンコール開発者
  • ステータスページ（問題が起きた時に顧客が状況を把握するためのもの）
  • 非難しない事後分析
  • エンベデッドチーム
  • クラウド
  • アンドンコード（異常を検知する）
  • 依存性注入
  • ブルーグリーンデプロイメント
  • カオスモンキー

非難しない事後分析

  • 48時間以内に行う
  • 全員が協力してタイムラインを作成する
  • 当事者以外を話し合いの進行役にする

「目的は過程の究明で、責任の追及ではない」

  • インシデントの記述
  • 原因の記述
  • 収拾または復旧の経緯
  • 事態の推移と対応のタイムライン
  • 顧客が受けた影響
  • 教訓、改善点、対策

DevOpsのツール

ツール選定の基準 - プログラマブルである（CLIやAPIから操作可能であること） - 検証可能である - 使い勝手が良い

DevOpsのマネジメント

ベストプラクティス - 複数の機能を持つ独立したチームに組織を再編する - 社員の不安を理解して解消に努める - リーンなアジャイルプロセスを使う

※リーンとは、無駄を省いて価値を最大化するという考え方

インフラの自動化

構成管理 - プロビジョニング（サーバー上にアプリケーションを運用可能な状態にすること） - デプロイメント（システムを運用・更新すること） - オーケストレーション（複数のシステムの依存関係を管理し、調和のとれた状態にすること）

インフラの構成管理ツール - Juju - teraform

  • Chef
  • Puppet
  • Ansible
  • CFEngine
  • Salt

サービスディスカバリーツール - etcd - Zookeeper - Consul

CMDBとは

コンテナのオーケストレーション - Docker Swarm - Kubernetes - Mesos

継続的デリバリー

継続的インテグレーション
アプリケーションのビルドと単体テストを自動的・頻繁に行うこと

継続的デリバリー
変更内容を都度、本番と同等の環境にデプロイして、統合テストと受け入れテストを自動で行うこと

継続的デプロイメント
変更のたびに全体を自動テストにかけて、本番環境に自動的にデプロイすること

  • 成果は小出しにするほど良い
  • WIPをため過ぎない
  • デプロイ単位が小さいので障害が発生したときに、原因を特定しやすい

継続的インテグレーションのコツ

  • ビルドは5分以内
  • コミットはできるだけ小さくする（わかりやすく、エラーを見つけやすい）
  • 壊れたビルドを放置せず、チーム全体の責任とする
  • トランクベースの開発フローの採用（ブランチを長時間残さない、コード内にフィーチャーフラグを入れる）
  • 不安定なテストは放置せずに修正する
  • ビルド実行時にステータス・ログ、アーティファクト（ビルド番号を付与）が出力されるようにする

※トランクベースの開発フローの採用とは
トランクベース開発フローは、Gitなどのバージョン管理システムを用いて、メインブランチと呼ばれる単一のブランチを中心に開発を進めていく手法。従来のブランチベース開発とは異なり、開発者は頻繁にメインブランチへ変更をコミットし、コードレビューや自動テストを経てマージしていくのが特徴。

継続的デリバリーのパイプライン

  • ビルドは一回限りとし、前環境に統一する
  • アーティファクトはいかなる変更も禁止する（ステージ間で差異がない状態）
  • どこかに問題があればデプロイを停止する（問題があれば次に進めず、チャットで通知等の仕組化がポイント）
  • デプロイの冪等性を保証する

継続的デリバリーのツールチェーン

パイプラインツールは、最適な組み合わせを調査する必要あり - バージョン管理 - 継続的インテグレーション（CI）システム（Jenkins、GoCD） - ビルド（Maven、Gulp、Packer） - テスト（Robot、Protractor、Cucumber、SauceLabs、Selenium、ChefのKicthenCI、ApacheBench、JMeter、Gauntlt、Mittn、Brakeman、Veracode） - アーティファクトリポジトリ - デプロイ（Rundeck、UrbanCode、ThoughtWorks、Deployinator）

運用

複雑なシステムはなぜ故障するか

  • 変更は新たな形の故障を招く
  • 複雑なシステムに内包される故障の組み合わせは常に変化している
  • すべての複雑なシステムは常に劣化したモードで動いている

計測（モニタリング）

  • サービスパフォーマンス・アップタイム
  • ソフトウェアのコンポーネント（ポート、プロセス）をレイヤー単位でホストの動作を計測
  • システムリソース（CPU、メモリ）
  • アプリケーション（テレメトリーから振る舞いを推測）
  • パフォーマンス ※APM（アプリケーションパフォーマンスモニタリング）、RUM（リアルユーザーモニタリング）
  • セキュリティ

ログ

ログの5要素 - 何が起きたか - いつ起きたか - どこで起きたか - 誰が関与したか - どこから来たか

ログの集約化 - 使う予定がないログデータは集めない（システムの負担になる） - 役立つ機関を過ぎたデータは処分する（リソースと保守の負担増加の原因） - アラートは緊急事態に絞る - 本番以上の可用性やセキュリティをログに求めない - ログも変化する

SREのツール

サービス形式のモニタリングツール - Nagios - zabbix - Pingdom - Datadog - Netuitive - Ruxit - Librato - NewRelic - AppDynamics

オープンソースのモニタリングツール - StatsD - Granglia - Graphite - Grafana - InfluxDB - OpenTSDB - Dropwizard

指標収集用のライブラリ - Metrics - Icinga - Sensu - Prometheus - Sysdig

  • Splunk

  • logstash

  • Kibana

インシデント管理ツール - PagerDuty - VictorOps

flapjack

オーケストレーション - rundeck - SaltStack - rerun

Reference