技術者が紹介するNTTPCのテクノロジー
gplus はてなBookmark

その他

DevOps体験談

2018.6.21

サーバ-エンジニア
木次遼太
取得資格:LPICレベル3「Core」 / ITIL Foundation / Ruby Association Certified Ruby Programmer Silver

こんにちは。
NTTPCコミュニケーションズにてシステム運用をしている木次と申します。

本記事では、最近よく聞くワードである「DevOps」について私のチームの取り組みを交えて紹介したいと思います。

DevOpsってなんなのか?
DevOpsを実現するためにはどうするべきか?

少しでもヒントとなれば嬉しいです。

■DevOpsをはじめよう

私は8年間、サーバーの運用チームで仕事をしてきました。
開発から受け取ったアプリケーションの品質を担保しサービス向けのシステムに適用、運用することがミッションです。

ここ数年を振り返ると、年々、新しい機能を多く、早くリリースすることを求められてきており、サービス開発に割く時間が増えてきているように思います。

このままでは、品質を保ったまま要求に答えるのは難しいと感じていたところ「DevOps」に取り組もう!!と宣言がありました。

今のままでは、世の中のスピードについていけなくて、なんかしらの打開策が必要だったんです。

■5つのキーワード

「開発と運用が協調して、開発スピードを向上する」
調べてみると、だいたいこんなことが書いてあります。

成功体験もたくさんあるようです。

でも、なかなか具体的なイメージが湧きませんよね。
社内で話を聞いてみても、イメージを持っている人は少ないし持っている人たちの間でも、バラバラでした。

そこで、まずは正しいDevOpsを教えてもらおう!ということで有識者にセミナーを開催してもらいました。

どうやら、DevOpsとは
・文化(環境)の変化
・無駄の排除
・自動化
・測定
・共有
から成るようです。
これらができている状態をDevOpsというみたいですね。

■具体的な目標が大切

従来と比較して3か月早いリリースを要求されたプロジェクトに試しにDevOpsを取り入れてみました。

「3か月の短縮」を達成するためには、組織横断のチームが一体となって開発プロセスを改善することが求められます。

具体的には、開発と運用のテスト環境の統一、上流工程への運用参画、自動化を中心にプロセスを変更しました。

大きくやり方を変えることになりましたが、無事目標を達成できました。

共通の具体的な目標があったので、各組織内での部分最適改善にならず大きな効果を得ることができたのだと思います。

これを踏まえて、会社規模で目標を設定することでより大きな範囲でDevOpsを進めたいですね。

■環境が文化を決める?

Devの開発環境、Opsの商用環境、もっといえば営業用のデモ環境でそれぞれのインフラを持っています。

これって、DevOpsからは離れた思想です。
各々の文化の中で構築した環境上で、他組織の環境やプロセスに配慮した仕事をするのは困難です。
逆に、環境さえ統一されていれば、他組織の動向を意識しやすく自分たちの文化を見直すことに繋がりやすいです。

この考えに従って、新たに構築した共通のインフラ上でデプロイや結合テスト、デモを実施するようにプロセスを変更してみました。

■目指せワークアラウンド0

システム運用において、実は必要だった要件が仕様に含まれていなかったり長期運用をするには十分な機能を備えていないことがよくあります。

そういったケースでは、即時対応を求められることが多く機能を追加している余裕はないため、だいたいはワークアラウンドを行います。

運用者から見ると、こういった事態はあらゆる仕事の計画を流してしまうやっかいなものです。

ここで問題となったのは、運用者がシステムの商用展開も兼ねているのでワークアラウンドが重なると、継続的デリバリーができなくなってしまう点です。
短い期間でサービスをリリースすることが難しくなってしまいます。

そこで、運用者が上流工程に参画し要件定義のフェーズにおいてバックアップやデータの蓄積量、故障や災害対応といった運用に関する事項を盛り込むことにしました。
ここで重要だったのは、アウトプットとして運用側の要望を残しておくことです。
今まで意識してこなかった項目なので、口頭だけでは取り漏らす可能性が高いです。
※IPAの「非機能要件グレード」を使ってみました。

結果として、運用における不測の事態は減少し、運用が安定してきています。

この活動を進めていくことで、ワークアラウンド0を目指しています。

■自動化を支援する

DevOpsを進めるにあたって、私たちが使っている自動化をサポートするツール群を紹介します。

・gitlab
・jenkins
・ansible
・cucumber

これらを共通PF化して、全社的に使い始めました。
利用者は、各ツール内で必要とされるコードを書けば、すぐにCDCIを実現できます。

具体的には、次のような動作です。

①gitlabにアプリケーション、Ansible playbook、cucumberコードをpush
②jenkinsからansible playbookをキック (自動デプロイ)
③jenkinsからcucumberを実行 (自動テスト)

使いやすいように、これらのツールのアカウントは一元管理されています。

プロジェクトを進めながら自動化も行うのは、非常に難しく労力がかかります。
従来の工程に加え、自動化を実現するための設計やコーディング、動作環境の構築をする工程が必要となるためです。

共通PFを活用することで、この工程を簡素化することができ、DevOpsを取り入れるハードルが低くなります。

■まとめ

今回は、私たちが取り組んだことの中でも特に重要だと思ったところをご紹介しました。

ご紹介した内容は
①最終的なイメージを共有する
②具体的な目標を設定する
③そのための環境を整理する
④上流工程を強化する
⑤自動化を支援する

となります。

最後まで読んでくださりありがとうございました。