システム開発と運用の現場の課題と解決策

Related Videos


開発が順調に終わっても油断は禁物 本番環境への展開で起きやすい「うっかりミス」を防ぐ

システム開発と運用の「うっかりミス」が最も起こりやすく重要視されるポイントは、開発環境から本番環境へシステムを反映させるフェーズである。特に開発と運用の職務分掌が明確な場合において、リリース担当者は大量のモジュール1つ1つについて、手順書を見ながらリリース作業を行っている。こうした手作業でミスをなくそうとしても限界がある。

しかし、このリリースプロセスに特化した自動化を進めれば、ミスを無くして品質を向上させることができる。



うっかりミスに気づかないケースも。気づいたときにはすでに重大な障害が!

システム開発と運用の現場において、十数年前から問題視されているのが「うっかりミス」である。システムリリースの失敗や遅延、もしくは水面下で対処してきた「ヒヤリ」「ハット」をもたらす「うっかりミス」はいまだに残っており、二重、三重のチェック体制を敷いているものの完全になくならないのが現状だ。品質の高い開発を行ったとしても、本番環境へのリリースでミスをすれば、今までの努力の何もかもが無駄になってしまう。例えば、コマンドの入力ミスが原因で、古いバージョンのモジュールを本番環境にリリースしてしまうケースがある。

こうしたミスでアプリケーションが止まれば、すぐに気づいて対処することができる。しかし、気づかないまま見過ごされるケースも少なくない。ようやく気づいたときには、重大な障害に発展していたり、顧客に迷惑をかけたりしてしまっているかもしれない。

なぜ、うっかりミスはなくならないのかー。そこには、手作業に頼ったリリースプロセスの限界がある。とりわけ、この問題が切実なのは銀行、保険、証券などの金融業界だろう。そこには、「開発と運用の分離」というルールがある。開発者がそのまま運用を担当すれば不正の可能性を排除できないとの理由で設けられた統制だが、複雑な手順書を介した手作業がミスにつながることが多い。

しかし、開発した部隊が運用を担当する場合には、このようなミスは起こりにくい。ただし、開発されたプログラムのモジュールは、開発SIerが異なれば、別の方法で管理されている場合が多い。プログラムは企業として一元管理されていないがために、バージョン管理も担当者任せ。ミスが起こる余地はなお残されている。



開発スピード向上が求められるなか、人海戦術のリリースは限界がある

以下では、開発と運用の分離が求められる企業、特に金融業界を念頭にリリースプロセスの品質向上と効率化について考えてみたい。

先に、煩雑な手順書について触れた。この手順書は多くの場合、Excelで記述されており、開発者によって手順書の形式もバラバラだ。勘定系システムの開発など大きなプロジェクトになれば、多くの開発者が参加している。金融機関のIT 部門には、毎日のように新たに開発されたモジュールと手順書が開発者から送付されてくる。数年に及ぶ大規模プロジェクトなら、モジュールの数は万単位になるかもしれない。

膨大な数のモジュール1つ1つについて、IT 部門のリリース担当者は開発者が作成した手順書を見ながらコマンドを打ち、間違いないことを確認したうえで本番環境への移行作業を行っている。

金融機関のなかには、専任のリリース担当者として数人配置しているケースも少なくない。ただ、手順書のコマンドの意味を理解できるスキルを備えた担当者を配置する余裕のない現場もある。これらの意味が分からなければ、入力ミスの確率は高くなるだろう。

人海戦術のリリースプロセスには、あちこちに大小の落とし穴がある。例えば、コマンドの入力間違い。何千、何万というモジュールについて、それぞれに対応する手順書に沿ってコマンドを入力するのは骨の折れる仕事だ。しかも、開発者ごとに手順書の形式が違ううえ、OSによってコマンドも変わる。リリースにかかわる業務は複雑であり、「ミスをするな」というほうが酷である。

ほとんどの企業においては、開発されたアプリケーションのモジュールを格納する場所が一元化されていない。ある担当者はファイルサーバに、別の担当者はライブラリーのツールに保管しており、バージョン管理も不十分だ。こうした環境では、最新バージョンのつもりで古いものをリリースしてしまうといったミスを防ぐことはできない。

業務効率の観点でも、従来のリリースプロセスには大きな課題がある。開発者によって異なる形式の手順書を見ながら、担当者がコマンドを入力しているのだから相当の工数がかかる。また、作業履歴を残すためにチェックリストで管理しているケースも多く、それが工数を増やしている。またスクリプトを用意するケースもあるが、汎用的なものではなく開発するシステムが変われば役に立たない。今後のIT技術者不足や人材の国際化が進む中、このような手順書に頼ったリリース作業には限界がくると思われる。





一元管理で業務効率を高め、ガバナンスを向上させる

リリースプロセスにおける複雑性、非効率といった課題に対するソリューションとして、近年注目が高まっているのがリリースオートメーション、つまり自動化というアプローチである。

リリースプロセスの複雑性について言及したが、実は、その業務の中身は「モジュールをアップデートする」「ファイルを転送する」のように定型的なものである。手順書の形式を統一するだけで一気に単純化することができる。単純化できるなら、退屈してミスを起こしやすい人間の手に頼るよりも、コンピュータに任せるのが得策だ。それが、リリースオートメーションである。

リリースプロセスにはいくつかのパターンがある。典型例は「AがBに対して、Cを実行する」というもの。自動化プログラムとして必要なパターンの数だけバリエーションを用意しておけば、開発側に求められるのは、「A 」「B 」「C 」などに該当するサーバ名やプログラム名などのリスト(XMLファイル)だけ。面倒な手順書の作成は不要だ。リストを受け取ったリリース担当者がこれをコンピュータに入力すれば、自動的にリリースプロセスが進行する。変数としてのリストとプロセスを切り分けることで、汎用的なプロセスを使い回すことができる。

リリースオートメーションにより、リリース業務は大幅に効率化される。おそらく、専任の担当者は不要になるはずだ。加えて、ガバナンスの確立という効果もある。分散して保管されていたモジュールは、プラットフォーム上で一元管理される。バージョン管理や変更管理も実現できるので、コマンド間違いによるリスクは最小化される。もちろん、「誰が、いつ、何をリリースしたか」という情報はログとして残される。

以上で説明したリリースオートメーションを実現するのが、C A Te c h n o l o g i e s の「C A R e l e a s e Automation」である。CA Release Automationは世界中の多くの企業で導入されている。導入実績は約200社。そのなかには、毎日膨大な数のサービスを更新している大手インターネット企業も含まれる。インターネットバンキングや勘定系システムの運用で、CA Release Automationを活用している金融機関も少なくない。多くの運用現場で実証されたCA ReleaseAutomationは、日本企業の間でも注目度が高まっている。

CA Release Automationの特長の1つが、700種類以上のアクション部品である。そこにはファイル操作やOS操作、メール、SNMP、XML操作などの自動化アクションに加えて、アマゾン ウェブ サービス(AWS)など外部クラウドサービスやVMwareの仮想化ソフトウェア、WebSphereやJBossなどのアプリケーションサーバ、各種CA製品に対応する部品も含まれている。

また、操作性に優れたグラフィカルユーザインタフェースも大きなポイントだ。コマンド入力は不要なので、担当者にはコーディングスキルもいらない。画面上でアクション部品を選択し、ドラッグ&ドロップで並べるだけで、簡単にリリースプロセスをつくることができる。

CA Release Automationは人間系の作業をなくしてミスを排除するとともに、職務分掌も担保する。すでにCARelease Automationを導入した国内金融機関の事例では、従来2人がかりで3日を要していたリリース作業が数秒に短縮された。もちろん、一元管理によるガバナンス向上にも貢献するソリューションだ。



Ⓒ2015 CA. and / or one of its subsidiaries. All Rights Reserved.

システム開発と運用の現場の課題と解決策

開発が順調に終わっても油断は禁物
本番環境への展開で起きやすい「うっかりミス」を防ぐ


TEL
0120-702-600
お問い合せ