リリース手順を把握している担当者が1人のみ
プロセスが1人のエンジニアの頭の中にしか存在せず、その担当者が休暇を取るとすべてのリリース作業が停止します。
DevOpsサービス
ユーザー数の少ない時間帯を選択することなくソフトウェアをリリース
HiTechCloudはCI/CD pipeline、コードとしてのインフラ、監視システムを構築し、開発チームが1日に何度もデプロイでき、必要に応じて数分でロールバックできるようにします。当社のDevOpsケイパビリティは、AWSよりDevOps Competencyとして認定されています。
- 認識された能力
- AWS DevOps Competency
- スコープ
- CI/CD · IaC · Container · 監視
- パートナーシップモデル
- プラットフォームの構築、併走支援、またはフル運用
- プラットフォーム
- HiTechCloud · AWS · オンプレミス
概要
DevOps は手作業を削減すること、ツール購入ではありません
当社が接する企業の多くでは、リリース作業にいまだ手作業の工程が少なくとも一つ残っています。サーバーへのファイルコピー、データベース更新コマンドの実行、設定ファイルの1行修正などです。こうした工程があるためにリリース作業を深夜まで待たなければならず、金曜日に誰もシステムに手を付けられなくなる原因となっています。
当社の仕事は、それぞれの手動ステップをコードに変換することです。リポジトリから再構築可能なインフラストラクチャ、パイプライン経由で自動的に実行されるリリース、すべての変更に誰が、いつ、何を実施したかの記録が残ります。
結果は測定可能でなければなりません。デプロイ頻度、commit から本番環境までのリードタイム、変更失敗率、復旧時間という4つのメトリクスを追跡し、印象に頼るのではなく前後を比較します。
よくある課題
リリースプロセスが開発チームの妨げとなっている兆候
テスト環境は本番環境と異なります
テスト環境では正常に動作するコードが本番環境でエラーになるのは、2つの環境が異なるタイミングで手動構築されたためです。
ロールバックに数時間を要する
リリースで障害が発生した場合、リカバリは手動で実施、バックアップからのリストアが必要な場合あり。
システムのどこが故障したのか不明
集中ログとメトリクスがないため、インシデント対応は毎回サーバーに個別ログインして原因を特定することから始まります。
サービス
デプロイの対象範囲
Pipeline CI/CD
commit から本番環境まで自動化：ビルド、テスト、セキュリティスキャン、承認、環境ごとのデプロイ。
コードとしてのインフラ
インフラ全体を Terraform または同等のツールで記述し、新しい環境をリポジトリから迅速に再構築できるようにします。
Container とオーケストレーション
Docker でパッケージ化し、Kubernetes または管理型コンテナサービスにデプロイ、リソースポリシーと自動スケーリング付き
監視とログの一元化
メトリクス、ログおよびトレースを一箇所に集約し、ビジネスに意味のある閾値でダッシュボードとアラートを設定します。
パイプラインに組み込まれたセキュリティ
依存関係とコンテナイメージをスキャン、集中管理されたシークレット、ロールベースアクセス、完全なデプロイ監査ログ
社内チームへの引き継ぎ
プロジェクト終了後に自律運用できるよう、企業の技術チームへの研修およびメンタリングを実施します。
開始方法
1つのサービスを選択し、確実に成功させてから水平展開する
当社が最初からシステム全体のプラットフォームを一度に構築することはありません。まず 1 つのサービスをモデルとして選択し、新たなプロセスを一貫して稼働させた後、そのモデルを残りの部分へ適用します。
- 変更頻度は高いが中程度のリスクを持つサービスを選択。
- そのサービス用にパイプラインとコードとしてのインフラを構築します。
- 適用前後の4つのメトリクスを測定します
- 次へ展開するサービスで再利用可能なテンプレートとして標準化。
プロセス
DevOps プロジェクトの進行方法
-
01
現状評価
リリースプロセス、環境、ツールを見直し、現在のメトリクスをベースラインとして計測します。
-
02
プラットフォーム設計
既存チームと既存インフラに適したツール選択、環境設計、権限設定、承認プロセスの構築。
-
03
パイロット実装
単一サービス向けに pipeline およびコードとしてのインフラを構築し、本番稼働させながら安定するまで調整を重ねます。
-
04
段階的展開
残りのサービスにテンプレートを適用し、各部分に監視とドキュメントを追加します。
-
05
ナレッジトランスファー
社内チームへの研修を実施し、運用ドキュメントの引き渡しおよびプロジェクト後のサポートモデルを合意します。
提供方法
1 ステップずつ自動化、各ステップは取り消し可能
プロセス全体を一度に変更することはありません。自動化された各ステップは、チームが信頼するまで従来の方法と並行実行されます。
- pipeline が安定するまで、従来のリリース方法が利用可能なままです。
- すべてのインフラストラクチャ変更はソースコードリポジトリ内に存在し、履歴を確認できます。
- 本番環境へのデプロイ権限は、pipeline の編集権限から分離されています。
テクノロジー
一般的に使用するツール
ツール群は企業の既存インフラとチームのスキルセットに応じて選択され、特定の技術スタックを固定的に強制することはありません。
CI/CD
- GitLab CI
- GitHub Actions
- Jenkins
- Argo CD
Infrastructure as Code
- Terraform
- Ansible
- CloudFormation
- Packer
Container
- Docker
- Kubernetes
- Helm
- Harbor
監視およびログ
- Prometheus
- Grafana
- Loki
- Elastic Stack
- CloudWatch
顧客
本サービスの対象
手動でリリースしている開発チーム
- 新バージョンのリリース作業が、担当者の記憶頼みの手作業に依存しています。
- リリースのたびに利用者が少ない時間帯にスケジュール設定する必要がある。
- リリース失敗後のロールバックに数時間かかり、確実ではありません。
環境が一貫していない複数の企業
- テスト環境と本番環境が異なる時期に手作業で構築されました。
- 新規プロジェクト用の環境構築に数日を要する
- 設定が分散しており、ソースコードリポジトリ に保存されていない。
自分たちで実行したいと考えているオペレーションチーム
- エンジニアは在籍しているものの、完全な pipeline を構築した経験がありません。
- 各サービスで最初からやり直すのではなく、再利用可能なテンプレートが欲しい。
- プロジェクト終了後に自社で運用するため引き渡しを希望します。
FAQ
よくあるご質問
開発者が数人しかいないのですが、DevOps は対応できますか。
必ずしもそうではありません。小さなチームの場合、パイプラインの自動化とコードとしてのインフラが通常十分で、Kubernetes は後でかまいません。全体をそのまま導入するのではなく、実際の規模に適した水準を提案します。
Kubernetesの使用は必須ですか？
いいえ。Kubernetesを導入する価値があるのは、サービス数やスケーリング需要が十分に大きい場合のみです。多くのシステムは、仮想マシンやマネージドcontainerサービスを利用した方が、はるかに低い運用コストで安定して稼働します。
HiTechCloudは構築して引き渡すのか、それとも長期運用するのか
両方が可能。プラットフォームを構築して内部チームに引き継ぎさせたい企業もいれば、長期サービス契約で運用を完全に委託したい企業もいる。
本番環境のシステムをデプロイのために停止する必要がありますか。
いいえ。pipeline とコードとしてのインフラは個別の環境で並行して構築され、安定稼働が確認され検収が完了した後にのみ本番運用へと切り替えます。
現在のリリースプロセスをベンチマーク
お問い合わせください。HiTechCloud がお客様のリリースプロセスを確認し、手作業ステップを指摘し、チーム規模に適した自動化範囲を提案します。
