継続的デリバリと旧式ネットワーク機器
はじめに
NetOpsCoding Advent Calendar 2016 - Qiita の19日目の記事です。
前に書いたブログの記事で「Bere-metal/White Box Switchとか結構いいよね」みたいな話をした。ただ「じゃあ全部White Box Switch買い換えよう!」とは現実的にはならない。性能的な面もあるし、単純に欲しい要件、機能に合致しないだとか、いざという時のベンダーサポートはやっぱりほしい、そもそもお金がないなんて話も。
では旧式のネットワーク機器はどうするんだ?といった話になると思うはず。これらに対して既存の各種ツールをどう適応するかを継続的デリバリの説明を交えて今回考えてみる。ほんとに考えただけなので細かい部分に関してはいろいろツッコミもあると思うし、あまり丁寧な説明ではないところもあるので注意してほしい。
今まで出てきたツールを整理しよう
今まで話したツールをまとめてみると
- バージョン管理システム
- ビルドツール
- テスティングフレームワーク
- 継続的インテグレーションツール
といったものがある。ただ「これってソフトウェア開発で使ってたツールだよね」と思うはずだ。しかし、前回「ネットワークの継続的インテグレーション」で出てきた「構成管理ツール」によりサーバ周りの状況が一変する。
サーバ構築ではShell Scriptなどを使った構築用のプログラムを使うこともあったが、これには問題があった。
- コマンド入力後の出力結果を考慮し、行う作業を変更する必要がある
- 誤ってプログラムを数回実行した場合、単純な作りだと複数設定が追加されたり、ほかの設定を上書きするなどサーバ設定に問題が出る
- プログラムを作りこんでしまうと、作成者にしか扱えなくなる
こういった背景から、個人があまり作りこまなくても、サーバ構築の手順を記述でき、皆で使用できるものが必要とされた。「構成管理ツール」はそういったサーバ構築に特化したソフトウェアである。ここではChef*1とInSpec*2の例を出して説明する。
file "#{ENV['HOME']}/test.txt" do content 'This file was created by Chef!' end
公式から抜粋。上記のコードは、テキストファイルを作成するだけだが、書き方を変えればパッケージをインストールしたり、サービスを起動するなどのコマンド実行をコードで表現できる。これらのコードをテストするには サーバ用のテスティングフレームワークを使用する。
InSpec Tutorial: Day 1 - Hello World
公式から抜粋したコードを少し変更。上記のコードで「This file was created by Chef!」と書かれたtest.txtがあるかをチェックできる。
このようにサーバ構築の作業内容を、コード化し、コマンド1つでそれらの手順を素早く実行できる。また確認作業もコード化する。サーバの構築手順がコード化されると、ソフトウェア開発で使われていた技術を適応しやすくなる。Infrastructure as Codeの誕生だ。
simplearchitect.hatenablog.com
単にツールを使うだけではなく、アジャイルソフトウェア開発で適応されていた経験則(プラクティス)なども適応する。バージョン管理、継続的インテグレーション、コードレビュー、リファクタリングなどが代表的なものだろう。
継続的インテグレーションでは、常に「完成品のソフトウェア」が開発環境に置かれるが、本番環境への投入まで行かなかった。Infrastructure as Codeの恩恵により、開発環境から検証環境、検証環境から本番環境への移行時間が短縮され、いつでも「完成したサービス」を届けられるようになった。これが継続的デリバリ(Continuous Delivery)だ。
ネットワークに置き換えよう
下記の図は、Infrastructure as Codeでよくある構成だ*3ネットワークに適応するには何が足りないだろうか?
PC・ビジネス | FLAT ICON DESIGN -フラットアイコンデザイン-
Chef/Git/Oracle VM VirtualBox/GitLab/Jenkins
すぐに思いつくのは「構成管理ツール」と「テスティングフレームワーク」だ。じゃあこれを作ればよいのかと思うが、ネットワーク機器の設定ファイルを思い出してほしい。これはコードではないだろうか?
ネットワーク機器にはFTPを使って設定ファイルのバックアップしたり、設定ファイルをFTPで取得してネットワーク機器に適応するコマンドが存在する。つまり設定ファイルさえあれば、ネットワーク機器へログイン/設定ファイルを投入する程度の操作で済む*4。この部分の操作をexpectなどで自動化しておけばAPIなどを持たない旧式のネットワーク機器などにも比較的楽に設定投入が可能だ。
設定ファイルの作成を楽にしたい場合はヒアドキュメント使うのが手っ取り早い。ただ、設定項目が多くなった場合はこれでは綺麗ではないのでERBを使うのも良いかもしれない。PythonならJinja2などだろう。
テスティングフレームワークに関してはNetOpsCodingなどで取り上げられている物を使用するのもアリだ。また簡単なネットワークの疎通テストをするだけであれば、CIツールのJenkinsが持つslave agent機能を使って[Pingを行うNode] [パケットキャプチャを行うNode]などを立てて置き、それらにJobを実行させるのもいいだろう。これらのログはすべてJenkins上で見ることができるし、Jenkinsfileを使用すれば細かいJobの設定を行うことができる。
あなたの目的は何ですか?
とりあえずいろんなツールを出してみたものの現実は非情である。これらのソフトウェアを採用するのが正しいか、正しくないかは「あなた」もしくは「チーム」が、さらには「組織」がどんなことで困っているかにもよる。ツールを採用するのも、チームの運用に口出しできる程度の業務権限が必要だし、チームメンバはソフトウェアの使い方を覚える必要がある。導入したけど「何が便利なのかわかりません」「今までよりも仕事が増えました」というのもざらにある*5。
「もう小学生でもプログラミングできる時代になっているので、コードが書けるだけなら小学生以下だよねということは言いたいですね」
以前一緒に仕事をした熟練のプログラマも似たようなこと言っていた。いやだなー。怖いなー。
この話は、プログラミングができるだけではなく、そのプログラムによって「何をして」「どう便利になり」「いかに稼ぐか(or 費用削減するか)」という目的の部分を指している。ネットワークに対してInfrastructure as Codeを適応する際にも考えられる。果たしてあなたはネットワークの何を、どう便利にして、結果どういった利益を得たいのか?そこを明確にするために、現在の作業手順や、運用を振り返り、そこに今まで出てきたソフトウェアをどう適応するかを考える必要があるだろう。
まとめ
- 構成管理ツールによりサーバ構築の手順がコード化されるようになった。
- ソフトウェアの手法をインフラに取り入れるInfrastructure as Codeというものが出てきた。
- 不足している部分もあるがネットワークにもこれらを適応できるのではないか。
- 不足している部分も、既存技術の組み合わせなどで対応はできる。
- ただし、自分たちにとって本当に必要なものを選択する必要がある。
*1:Ansibleは楽だが、ちょっと複雑なことをしようとすると面倒だったりする。また、サーバ向けのテスティングフレームワークはRubyのRspecベースがほとんどで、Rubyの知識が必要になる。構成管理ツールもRubyで書けるほうが設定情報の共有などしやすく、書き方も混乱しないので個人的にはChef良さそうだなと思ってる。
*2:Serverspecでも良かったが、Chefの公式見たらInSpecというテスティングフレームワークあったので引用。書き方はServerspecと同じようなところもあるが、一部機能拡張されていたり、方向性の違いが見える。
*3:GitHubやCircleCIでも良かったが、たぶんネットワークの人とかは手元の環境で使用できるソフトウェアのほうがよさそうな感じがしたので。
*4:コンフィグ投入時における、設定反映・各種プロトコルなどに起因するネットワーク断時間だとかはあんまり考えてないが。
*5:ほとんど構成が変わらないネットワークがあったり、設定手順が定型化できない作業も存在する。そういったネットワークの自動化コードを書いても、大きな効果があるようには思えない。
ネットワークの継続的インテグレーション
はじめに
ブログの初めに、「ネットワーク寄りのソフトウェア開発者のはず」とか書いたのに大してネットワークの話をしてなかったなーと思ったので、前回話した継続的インテグレーションに絡めたネットワークの話をしようと思う。
Bere-metal? White Box? Branded?
私はそこまでOpen Stackには詳しくないのだが、面白そうなセッションがあったのでOpenStack Summit 2016に参加した。お目当てのセッションが始まる前に企業ブースを回っていた時に見つけたのが、Dellの「Dell Red Hat OpenStackCloud Solution Reference Architecture Guide」という冊子。
正直構成そのものより、その構成の中で使われていたスイッチに目が行った。ちょっと気になったので、製品担当の人に話そうと思ったら...なんか厚切りジェイソンみたいな人が立ってる。日本語が通じることを祈りつつしゃべりかけてみる。
- 私:「これってWhite Box Switchですか?」
- ジェイソンさん:「Branded Switchだよ。White Box Switchもあるけど」
良かった。日本語通じた。そっか、Branded Switchか...という事でここで解説。
Forrester Researchのアナリスト曰くForresterでは企業向けのネットワークスイッチを4つに分類している。
Proprietary switch(独占的なスイッチ)
ベンダー独自のネットワークOS、ハードウェアによって構成されるスイッチを指す。このネットワークOSとハードウェアは独自規格なので分離出来ない。なので両方購入する必要がある。ネットワーク機器は、サーバとは異なり特定用途(パケットの転送、経路の切り替えなど)に特化していたため、独自規格が多かった*1。基本的に高性能だが、採用している技術によっては特定ベンダー機器で固めないと機能を発揮できない。つまりネットワークの構成が特定のベンダー依存となる。こうなると、ほかのベンダーへの切り替えが難しくなる。余談だがプロプラエタリと名前がつくものは大抵、ロクな意味ではない。
Bare-metal switches(地金のスイッチ)
主にOriginal Design Manufactur(発注元のブランド製品を設計~製造する製造者)のスイッチで、ネットワークOSがインストールされていないものを指す。もともとネットワークベンダー製品の設計、製造を行っていた会社が、その技術を使い、独自ブランド製品として発売している。ただ流通、拡販などはやや弱く代理店経由が多い。また、ODMが提供する技術サポートはハードウェアに関する基本的なものだけで、ネットワークOSなどに関してはサードパーティの製品などを顧客が別途調達する必要がある。いわゆる玄人向けの製品。
White-box switch(公開された仕様のスイッチ)
Bere-metal switchだが、ネットワークOSがインストールされているものを指す。近年、ネットワーク機器も独自のハードウェア(カスタムシリコン)から、汎用的なハードウェア(商用シリコン)へと移り替わっており、その代表がBere-metal/White-box switchである。汎用/規格化されているのでサーバと同じように様々なOSをインストールできる。インストールされているネットワークOSは、White-box switchのベンダー、もしくはサードパーティ製の物がインストールされる。
Branded bare-metal switches(ブランド ベアメタルスイッチ)
Bere-metal switchだが、ODMによる提供ではなくOriginal Equipment Manufactur(ODMに比べ設計する能力のない製造だけを行う会社)により製造されたブランド付きのスイッチを指す。通常のBere-metal switchと同じように顧客がネットワークOSをインストールする必要があるが、ブランド元のベンダー企業によるハードウェアからネットワークOSに対する技術サポートを得ることができる。また流通、拡販なども通常のBere-metal switchに比べると格段に差がある。ジェイソンさんが言ってたのは多分これ。
Cumulus Networkが提唱するNetDevOps
ここで挙げられたBig Switch/Midokura/Cumulus NetworksはネットワークOSを提供する会社だ。この中でソフトウェアのツールを使いDevOpsを行おうと提唱しているのがCumulus Networksだ。この会社が提供するのはCumulus Linuxと呼ばれるLinux OSをベースとしたネットワークOSである。
why not use open source off-the-shelf automation tools that are already being leverage
なんで、もう活用されている既存のオープンソースの自動化ツールを使わないんだ
ネットワークOSとして動作するLinux OSという位置づけのため、サーバで利用できるソフトウェアがインストール可能とのこと。上記の図はサーバ構築に特化したビルドツール(構成管理ツール)であるChef/Ansible/Puppetを利用したケースである。
従来、ネットワーク機器への設定投入は
- 顧客もしくは社内の他部署からの要望を資料にまとめる
- まとめた内容をもとに検証環境のネットワーク機器を使ってコマンドを投入
- それをもとにコマンド投入の手順書を作成、手順書のチェックも行う
- 手順書をもとに商用環境のネットワーク機器に対してコマンドを投入
- コマンドによってネットワーク機器の設定が変更される
といったように手作業が多かった。時間もかなりかかる。Cumulus Networksが提唱するNetDevOpsではどうなるかというと
- 顧客もしくは社内の他部署からの要望を資料にまとめる
- まとめた内容をもとに検証環境のネットワーク機器設定を行う作業を手順を定義
- 作業を定義したコードのレビュー、動作確認を行う
- 商用環境のネットワーク機器に対して作業を定義したコードを実行
- コードによってネットワーク機器の設定が変更される
となる。商用環境に対しての作業は、作業内容を定義したコードを実行するだけ。手作業に比べて時間がかからないし、コード化(プログラム化)されているので同じ作業なら使い回しも効く*2。またCumulus Networks Blogの他記事ではバージョン管理システム、継続的インテグレーションツール、テスティングフレームワークなどの使用も推奨している。
導入している企業
- 私:「どうですか、売れてますか?」
- ジェイソンさん:「Branded Switchはそこそこ売れてますよ。ただWhite Box Switchに関してはサポートがないので、データセンタ事業者とか自前で何とかできる所しか買わないですね」
- 私:「White Box Switchは海外のデータセンタ事業者が結構入れてますよね。最近は日本のデータセンタも導入し始めてきていますし」
- ジェイソンさん:「White Boxは安いですからね。ただ、少し高いけどBrandedはサポートがあるからいいですよ*3」
こういった機器を導入し、効率化を図れる企業は限られている。ベンダーサポートに過度な依存をせず、自分たちに必要なものを見極め、自前の技術者で解決できるところでないと、効率的な仕組みを作り、運用していくのは厳しい。逆に言えば優秀な技術者を取り込み、彼らの意見を取り入れ、それを実現させる体制があれば、少額の投資で効率的な仕組みを作ることができるはずだ*4。
まとめ
- 従来、ネットワーク機器は特定用途に特化していたため独自の規格が多かった
- 低コスト、技術の普遍化/進歩により汎用的な規格が登場するようになった
- LinuxベースのネットワークOSにより、サーバ技術がネットワークにも使用可能
- ソフトウェア関連ツールの利用や、継続的インテグレーションの適応も視野に
- しかし、こういった技術を採用できる企業は限られている
*1:特定用途でしか使わないので汎用的にする必要もないし、専用のネットワークOS/ハードウェアとして設計した方が性能も出せる。
*2:頻繁に同じような作業を行うのであれば構成管理ツールは有用、異なる作業を行う場合は効果が薄い。ただ作業手順(コード)が必ず残されるのは便利
*3:物によって値段が上下するので一概には言えないのだが、Proprietary switch > Branded bare-metal switch > Bare-metal/White-box switch
*4:ただ、ここで述べられているのはネットワークが頻繁に変更されるシステムである。適材適所、費用対効果などを考えて技術を採用しなければ、無駄な投資で終わる。規模によってはベンダー製品に頼ってしまったほうが良い場合も、もちろんある。
いつでも完成品を 継続的インテグレーション
はじめに
エクストリームプログラミングには様々な良い経験則、習慣(ベストプラクティス)がある。その中でも有名なのは継続的インテグレーションだろう。
ここでは継続的インテグレーションが確立されるまでの流れに注目し、説明しようと思う。
いつでも完成品を
そもそも継続的インテグレーション(Continuous Integration)という単語から何を行うかが想像できるだろうか? 正直な話、私が初めてこの単語を聞いたとき、全くと言っていいほどピンと来なかった。
Continuousは時間的、空間的にに途切れなく続いているといった意味合いで、Integrationは統合、完成を表す。[いつでも完成品(or 統合)を]と言い換えれば少しイメージしやすくなるのではないか。完成品とはソフトウェアを指す。
どういった経緯があったのか?
[継続的インテグレーション]の流れを知るのにちょうどよい資料があるのでそれを見て行こう。
彼はデボン。継続的デリバリを実践している。彼はDevOpsマスターだ。
でも彼は常に優秀であったわけではない。彼の成長を見て行こう。
アジャイルソフトウェア開発のコンサルティングを行っているcPrimeという会社の資料だ。この資料では開発工程の変遷をデボンという人物の成長に見立てて説明している。
CIとはContinuous Integrationの略で、CDとはContinuous Deliveryの略だ。Continuous Deliveryは継続的デリバリと呼ばれている。先ほどと同じように言い換えると[いつでもお届け]といった感じだろうか。もちろんここで届けらるのはソフトウェア(もしくはソフトウェアによって提供されるサービス)だ。
DevOpsは、、、「開発者と運用者が仲良くして、お客様にとって有用なソフトウェアの機能を、1日に10回実装できるくらいに効率のいいチーム作ろうね」みたいなスローガンだと思ってもらえばいい。CD/DevOpsに関しては今回特に触れない。
赤ちゃんデボン ソースコードの管理
ソフトウェア開発は複数人で行う。ソースコードを各自で作成、編集し、それぞれが作ったものをまとめていくわけだが
- どのプログラムのファイルが最新で、最後に誰がいじったか分からない
- メンバーが作業用フォルダ、ファイルなどを作るのでフォルダが汚くなる
- それぞれのメンバーが作成したファイルを最後にまとめるのが面倒だ
といった問題が出てくる。上記の問題を解決するために出てきたのがバージョン管理システムだ。これを使うことによって、だれがどのファイルを編集したかが分かるほか、個々の作業環境を分割したり、成果物となるソースコードのまとめたりするのが楽になる。
幼児デボン 構築の自動化
ソースコードを[動くソフトウェア]として構築(ビルド)するのも手間がかかる。ソースコードを[動くソフトウェア]にするには
などの作業が必要である。構築作業を簡略化するために作られたのがビルドツールだ。ビルドツールで作業をあらかじめ定義しておくことで、構築作業を自動化できる。さらにビルドツールでは以前に同じ作業を行った場合はその作業を省略したり、ある作業がどの作業に依存しているかを確認してビルドの成否判断を報告してくれたりする。
少年デボン テストの自動化
構築ができたからと言ってそれが完成品となるわけではない。テストが必要だ。テストも繰り返しの作業が多い。
- プログラムが正しいかどうか判断するため複数のデータを入力し動きを確認する
- プログラムを変更した際に、予想外の変更が無いかどうか再度テストする
特にプログラムを変更した後のテストは同じことの繰り返しがほとんどだったりする。テストを自動化するために使うのがテスティングフレームワークだ。テスティングフレームワークを使ってテスト内容を定義しておくことで、テストを短時間で繰り返し行うことができる。またこのテスティングフレームワークはビルドツールから呼び出すことができるので、構築、テストをスムーズに行うことができる。
青年デボン いつでも完成品を (継続的インテグレーション)
ソースコード作成、構築、テストが完了すれば完成品と呼べるようなソフトウェアが出来る。各工程で作業を効率化するためのツールが生まれたが、これだけでは解決されない問題がある。
- バージョン管理システムを使っても、まめに管理をしなければ個々が管理するソースコードの中身が大きく乖離してしまい、ソースコードをまとめるのに非常に時間がかかる
- ビルドを自動化しても、それぞれの開発者が利用しているライブラリのバージョンや、開発環境などが異なる場合、うまく構築できずソースコードを書き直す必要が出てくる
- テストを自動化しても、要件や設計内容を意識してテストを設定しなければ、抜け漏れが多くなり見逃す欠陥(バグ)が増える。発見が遅れれば大変なことになり、もちろんソースコードを書き直す必要が出てくる
ソースコードが大きければ大きいほど問題が複雑になり、工程の後になれば、なるほど出戻りが大きい。ウォーターフォール型では[設計]がすべて終わった後に[開発]、[開発]がすべて終わった後に[テスト]といった手順で行う。そうすると必然的に大きな単位のソースコード取り扱う事になるため、複雑化し、各工程の人員も異なるので見逃しが起こりやすい。
プレゼントBOXのアイコン素材 | FLAT ICON DESIGN -フラットアイコンデザイン-
これを防ぐために考えられたのは小さな単位の機能ができたらすぐ、ソースコードを統合、自動化されたビルド、テストを行うといったやり方だ。一連の作業を小さな単位で行うことによって問題の発見を早め、かつ[動くソフトウェア]、つまり完成品を常に用意しておく。これが継続的インテグレーションである*1。
継続的インテグレーションツール
こまめに完成品を作るのは容易な作業ではない。[開発]、[構築]、[テスト]を何度も何度も繰り返さなければならない。1日に1回どころか、1日に複数回このサイクルを回すときだってあるはずだ。そうすると以下の要望が出てきても不思議ではない。
- 特定の時間や、ソースコードを統合したときなど、任意のタイミングで自動化されたビルド、テストを手作業(自動化ビルド実行するためのコマンド入力)無しで行いたい。
- 複数人が自動化されたビルド、テストを行っていても問題ないようにしたい。
- ビルド、テストの成否結果、実行ログなどを分かり易い形で閲覧したい。
そのために継続的インテグレーションツールが出てくるわけだが、ここまでの説明からこのツールの設計意図や機能などは想像するに難しくないだろう。これを使えば[開発]、[構築]、[テスト]にかかわる作業がよりスムーズになるはずだ*2。
まとめ
- ソースコードの管理のためにバージョン管理システムが出てきた
- ビルドツール、テスティングフレームワークなどの自動化ツールも作られた
- しかしこれらだけではソースコードの複雑さに起因する問題は防げない
- ビルド、テストを頻繁に行い、完成品を用意するという考えが生まれた
- [開発]、[構築]、[テスト]のサイクルを継続的インテグレーションツールで楽にする
*1:アジャイルソフトウェア開発の手法の多くでは開発対象の機能を小さな単位に分け[設計]、[開発]、[構築]、[テスト]を短い期間(1~2週間)で行い、それを繰り返す。こういった手順の背景には継続的インテグレーションの要素が含まれていると考えられる
*2:もちろんこれらを使いこなすための技術や、チームとしてのルールが必要だ
なぜアジャイルソフトウェア開発?
はじめに
前回のNetOpsCoding#3 勉強会参加の記事の中でアジャイルソフトウェア開発、エクストリームプログラミングなどの単語が出たので、ここで説明しようと思う。
アジャイルソフトウェア開発をただ、説明するのもアレなのでいつも通り「なぜ」それが必要になり、「どう」利用されるかを重点に書きたいと思う。ただ、今回の記事は「なぜ」の部分を中心とする。
ウォーターフォール型開発への批判
もともとアジャイルソフトウェア開発は、ウォーターフォール型開発に対する批判から始まった。ウォーターフォール型に関して書かれたWikipediaの記事を見てみよう。
「ウォーターフォールモデルは間違っており有害である。私たちはこのモデルから脱却しなければならない」 -Frederick P. Brooks Jr.-
「ウォーターフォール・アプローチは,危険かつ問題をはらんだ,企業における風土病」 -McBreen,P.-
「秩序正しく、予測が可能で、説明が付きやすく、測定可能なプロセスであり、文書を中心とした単純なマイルストーンが存在するという幻想をウォーターフォールがあたえた」 -Larman,C.-
酷い言われようである。なぜウォーターフォール型がこんなにも嫌われているかを見て行こう。
開発した45%の機能は一切使われない
ウォータフォール型の開発では、初めにシステム全体の要件定義(顧客が解決してほしい問題を聞き、どんな機能を作るか)を決める。この要件で定義された機能のうち、いったいどれほどの機能が使われているのだろうか?
以下の図はBig Requirements Up Front (最初にまとめて要件定義)で実装された機能がどれほど使用されているかという調査報告である。
Examining the "Big Requirements Up Front (BRUF) Approach"
報告によると45%の機能が一切使われず、19%の機能が稀に使われるといった結果だ。つまりウォーターフォール型の開発では約半分の仕事は全く意味のない作業という事になる。
顧客自身が自分の問題を把握していない、問題から必要な機能を絞れていない事もあるが、実際に物が出来て使ってみるまで分からないという事も影響してるだろう。
大規模伝言ゲーム
ウォータフォール型の開発では工程ごとに作業する人が異なる事が多い。[要件定義]を行う技術者、[設計]を行う技術者、[プログラミング]を行う技術者など様々だ。各技術者は単一の仕事の能力だけで済むというメリットも存在するが、デメリットも存在する。それはコミュニケーションの問題だ。例えば要件定義の工程を考えてみよう。
要件定義のある打ち合わせ例
- 顧客:「○○の機能ですが前の打ち合わせでは5秒くらいの処理時間と言いましたがそれはあくまで理想で、10~15秒くらいでもそんなに問題ないです。」
- 担当者A:(5秒の処理時間で終わるように実装しよう)
- 担当者B:(5秒が理想だけど、10~15秒でもいいんだ)
- 担当者C:(前に優先順位高くないって言ってたし10~15秒で)
簡単な打ち合わせだけでも担当者ごとに理解が異なる場合もある。相互にチェックし、調整ができれば問題ないかもしれないが、抜け漏れというのは発生する。これが設計担当、プログラミング担当、テスト担当へと話が伝わる時にはどうなっているのだろうか?
顧客が本当に必要だったものとは (コキャクガホントウニヒツヨウダッタモノとは) [単語記事] - ニコニコ大百科
伝言ゲームを防ぐために行われるのは大量の資料作成だ。顧客が述べた要件を事細かく記述し、誰がどう読んでも理解に差が出ないようにするのだ。え?顧客が言った要件が間違っていたので資料に手直しが必要? もう設計担当に渡した後なんだけど。
書類の文字をコードに落とし込むとき
なんだかんだで要件定義に関する書類が完成し、設計担当の手に渡った。設計担当はその情報をもとにプログラムの詳細を作っていく、操作画面はどんなデザインか、どういった画面の遷移をするのか、どういった情報が必要で、その情報はどういったやり方で入力、保存、処理、出力がされるのかといった様々なことを書く。ああそうだ、障害が起こった場合の対処、処理性能やセキュリティも・・・といったことを考慮しつつ(本当はもっと考慮すべき点があるが)、様々な資料を作る。よし時間がかかったが完成した。
アポロ誘導コンピュータ(AGC)のソースコードの隣に立つマーガレット・ハミルトン
よし、プログラミング担当が設計書を元に作り始めた。これでひと段落だ。そう思っていた矢先にプログラミング担当から電話が入る。
PG担当A:「ここの機能は、○○というやり方にしたほうが効率良くないですか?」
PG担当B:「××って今回使用するプログラム言語の機能にありましたっけ?」
なるほど、確かに○○はいい方法だ。そして××は言語の仕様を失念していた。書き直したほうがいいのだが、書き直してしまうと他のプログラミング担当に頼んだ部分も修正しなければ・・・だがもう他の担当は書き始めてしまっている。どうしよう・・・このまま進めるか。そして今度は要件定義担当からメールが来た。
要件定義担当:「お客様の部長さんから、要件を追加しろとの話が・・・」
顧客の満足度
現場は大混乱だ。仕様の変更、実装時に判明する考慮不足で資料の大量修正がかかる。下手をすれば、もう資料を残す余裕もないかもしれない。修正によって発生した遅延のツケはプログラム担当が支払う。それならばプログラム担当を増やせば大丈夫では・・・いや、後から入った担当者に関連資料や今作ってるプログラムの説明をしなければならない。どちらにせよ作業が遅れる。
こういった状況で作り出されたプログラムは果たして顧客の問題を解決できるものなのだろうか。顧客はIT投資といった名目で予算を取る。投資と銘打ったからにはそのソフトウェアは初めに掲げた目標を達成し、投入した金額以上の効果を上げてくれるはずだと。これでは全員が不幸になる道以外残されていない。
エクストリームプログラミングの登場
このままウォーターフォール型の開発を続けていても誰も幸せにならない。そういった中で登場したのがエクストリームプログラミングだ。
- eXtreme Programmingの魅力を探る エクストリーム・プログラミング - Wikipedia
顧客の要件は常に変化する、重要なのは[コミュニケーション]、[シンプルさ]、[フィードバック]でありそれらを実践するための[尊重]や[勇気]である。そういった事柄から開発中にすべき良い経験則、習慣(ベストプラクティス)を示している。これにはアジャイルソフトウェア開発の骨子となるものが数多く含まれている。
これらを実践すればより良い結果が*1・・・ん? でも待てよ。内容自体は確かにいいのだが、かなり面倒な作業もある。ルールにのっとって運用しないといけない部分もあるし、頻繁に同じような作業をしないといけない時もある。
そうだ、ソフトウェアをつかって自動化しよう。
NetOpsCoding#3勉強会参加の記事の中で出てきた技術の元となる思想が幾つか存在する。こういった成り立ちを知ることで、自動化関連技術をより深く理解できるはずだ。
まとめ
- アジャイルソフトウェア開発はウォーターフォール型の批判から生まれた
- 従来の要件定義の方法では45%の機能が一切使われない
- ウォーターフォール型の各工程で伝言ゲームが発生、要件変更も起こる
- 伝言ゲームを防ぐために大量の資料を作成するが裏目に
- ウォーターフォール型に対してエクストリームプログラミングが登場
次の記事ではベストプラクティスの継続的インテグレーションについて解説しようと思う。
NetOpsCoding#3 勉強会参加
はじめに
勉強会に参加したのでそのメモ書きをここに乗せよう・・・と思っていたら私よりも詳細にメモを取っていた方がすでに内容を挙げてくれていた。そういえば会場で私の隣に座っていた方がノートPCにMarkdown記法でガリガリメモを取っていたのを覚えている。もしかしたらその人かもしれない。
第1回から参加しているらしく、かなり詳細にメモを取って公開してくれているようだ。同じような事を書いてもしょうがないので、参加した際の所感を述べようと思う。
所感
ネットワーク運用技術者が9割、残り1割がソフトウェア開発者で、NWベンダの参加者は非常に少ない様子だった(おそらく数名程度)。ネットワーク運用技術者側からするとソフトウェア周りの知識、技術に非常に苦労しているのが感じられた。
主催者がGitHubでNetOpsCodingのリポジトリを公開する旨を話していた時に、「リポジトリの方針、Gitの運用、コードレビューが不明瞭では?」との質問が出ていたのも印象的だった。
自動化に関する話題によく出てくるツールである [バージョン管理システム/リポジトリホスティングサービス] [継続的インテグレーションツール] [構成管理/ビルドツール] [テスティングフレームワーク] などはエクストリームプログラミングの経験則(プラクティス)やアジャイルソフトウェア開発宣言、それ以前の知見などを元にして、開発に関する作業やチーム運用を効率よくするために作られている物であるという認識が私にはある。
これらのツールはサーバ・インフラの運用で適応された実績があるので、おそらくネットワーク運用でもこれらのツールが適応できるだろう。
だがネットワーク運用の中で何が問題で、それを解決するためには運用をどのように改善し、上記ツールをどの様に適応すれば効率が良くなるか、また上記ツールではどこが対応できなくなるのかといったことを考え、足りない部分のみを作成するといった考えが必要ではないかと思う。
車輪の再発明 - Wikipedia UNIX哲学 - Wikipedia
自動化ツールやスクリプトを使用しても、継続的に使用し続ける体制を作るのが難しいと話も出ていた。主な原因としては
- 人事異動によりシステム構築者がいなくなり、ノウハウが消失する
- プログラミングや関連ツールのスキル不足により、引き継ぐ人がいない
- 自動化ツール、スクリプトの保守/運用体制の弱さ(人数が割けない)
などが挙げられていた。こういったことを考えるとネットワークの自動化に関しては外部のソフトウェア開発者に頼るのもいいかもしれない。もちろん予算や上からの承認があればの話なのでまた難しい。
まとめ
- ソフトウェアなどによるネットワーク自動化の余地はかなりあるのでは?
- スキルセットの違いなどによりネットワークエンジニアが苦労している印象
- 自動化/可視化ツールの話は出ていたが運用にどう適応するといった話は少ない
- 仮に自動化できても継続的に技術を利用し続ける体制などに不安が残る
- 外部のソフトウェア開発者に頼るのも良さそうだが壁は多い
注意すべきプログラムの特徴
はじめに
前回の記事では、コンピュータとプログラムが「なぜ」作られ、「どう」使用されるかを説明した。
元々は人がすべき仕事、解決すべき問題を代わりに行わせる為であったが、今では様々な場面で利用されるようになった。しかし今日に至るまでプログラムの特徴というのは意外と変わらないものである。この記事ではプログラムの特徴について取り上げ、それがどのような影響を及ぼしているかについて説明したい。
プログラムの特徴
ハーバード大学の元教授であるShoshana Zuboffが発表した内容によると、ITの導入目的として[自動化]と[情報化]の2種類あるとされている。 (これらの内容は上記のサイトから一部引用した。こちらの記事についても参照してほしい)
現実世界の出来事を機械上で実行する
人の手を介さず、何らかの仕事を行うことができる [自動化]
現実世界で行われる仕事内容をプログラム化し、それを機械の上で実行する。コンピュータが出てきた当時は学術計算などが主な自動化の内容だったが、コンピュータの処理性能、通信性能の向上、入出力手段の多様化により様々なものに応用できるようになってきた。
現実世界と比べ情報共有や整理、加工を効率的に行える [情報化]
無料の写真: Sd, カード, データ, ストレージ, 技術, フラッシュ - Pixabayの無料画像 - 1137506
コンピュータに取り込まれた情報は0と1の電気信号に変換される。これらの共有、複製にかかるコストは現実世界のそれと比較できないほどに小さい。それに加え自動化の恩恵により現実世界では考えられない速度で情報の蓄積、共有、整理、さらには加工まで行えるようになった。
- 紙の地図やメモ帳はGoogle MapやEvernoteへ
- 個人の感想や体験は食べログ、価格.comなどの口コミサイトへ
- ソフトウェア開発現場の経験則は、GitHub/Jenkinsなどの各種ツールへ
プログラムの注意すべき点
さあ、ここからが本題だ。プログラムは現実世界の出来事を模倣し、それを人ではなしえない速度でそれを実行する。それが本当なら人々の仕事は年々減っていくはずだが、現実にはそうなっていない。
You can see the computer age everywhere but in the productivity statistics -Robert Solow-
コンピュータの時代は至るところに見えるが、生産性統計には表れていない -ロバート・ソロー-
Productivity paradox - Wikipedia, the free encyclopedia
プログラムにも問題が存在するからだ。
抽象的なものを許容できない、機械的な制約が存在する
基本的にプログラムは曖昧な事柄を許容することはない。例えば工場で生産されるネジの不良品分別を例に考えよう。
人が不良品の分別を行う場合は、良品/不良品の見本となるネジを見て、不良品の見本に近いネジを不良品として分別するはずだ。もちろん個人差があるので人によって不良品として扱う、扱わないの基準に幅があるだろう。だが細かいことを指示せずともある程度分別してくれるはずだ。
対してプログラムの分別は正確である。プログラムが行う分別はネジの重さ、長さ、ネジ先の径の大きさなど基準となる値を使い、その基準から外れているものはどんなに正常なものに近くても必ず弾く。ただ、正確ではあるが、時には人ではしないようなミスを犯す。例えばネジの重さ、長さ、径が基準値内だったがそれでも不良品を見逃してしまった。
そのネジにはネジ山が無かったのである。
プログラムは一から十までの指示をしっかりと行わなければならない上に機械的な制約も存在する。想定外のデータ入力などには特に弱い。数字の0に対して除算を行ってしまったときに発生する[ゼロ除算]、想定しているデータの型から外れた入力を受け取ったときに発生する[タイプエラー]などがそれだ。例外に対策をしておかなければプログラムが即座に停止する様な致命的な事態が発生する。
現実世界の出来事を正確に把握、表現する必要がある
プログラムは曖昧な事を許容することができず、機械的な制約があることが判明した。ただしそれ自体はそれほど問題ではない。問題は、この世の中は曖昧なことだらけであるという点だ。
さあ、自分たちが行っている業務を思い浮かべてほしい。自分たちが行っている業務を新入社員に教える時に、マニュアルは存在するだろうか? 存在しない? では教える時はどうする? 自分の経験をもとに新人を指導するだろう。でもそれはあなたの先輩や上司も全く同じ内容を新人に教えるという確証はあるのだろうか? 例えば仕事でわからないことがあったときに都度都度上司や先輩へ報告しろという人もいれば、とりあえず自分で考えてやってみろという人もいるだろう。
回りくどくなったが一言で言えば、みんな結構適当なのである。
それをプログラムで自動化するのは本当に骨が折れる。すでにマニュアル化してあれば楽だが、そうでない場合は業務内容の整備、共有するために社内調整が必要である。だが、、、その過程でいろいろな問題が発生する。情報の共有不足、発言力の不均等、各々の利害から生じる政治。しっかりとしたものが出てくるまで変更や時間がかかる。
一度しっかりとした業務手順が完成されプログラムが作成できても、人事異動、組織変更などの変化も後々発生するかもしれない。現実世界の事象が変化した場合、プログラムを変えるか、現実そのものを変える必要がある。プログラム側の制約などにより現実世界の曖昧な部分を正確にしたりすることもある。
ここまでに述べてきた[自動化]や[情報化]は実現すれば我々の仕事を楽にし、より良い情報を提供してくれるが、それを実現するには現実側の曖昧さや、プログラム自体の制約、業務内容の変化による影響に対し、適切な対応ができる体制が必要なのである。
まとめ
- プログラムには[自動化]と[情報化]といった特徴が存在する
- [自動化]と[情報化]により作業を減らしたり有益な情報を得たりできる
- しかしプログラムは曖昧さを許容できず、機械的な制約も存在する
- 現実世界は曖昧なことが多く、時間の流れにより変化が発生する
- これにより効果的な[自動化]、[情報化]を行うのが難しい