otrs x jobschedulerでリリース管理 - 20160912セミナー資料

Copyright©2016IOArchitectInc.

2016年9月12日

OTRSxJobSchedulerでリリース管理

　OTRS正規パートナー

株式会社アイオーアーキテクトwww.io-architect.com


会社紹介

会社名　　　　株式会社アイオーアーキテクト /　IO Architect Inc. (英記）

ホームページ　 http://www.io-architect.com/　

本社　　千葉県浦安市猫実1-20-43

設立年月日　　 2012年12月20日（第5期目）

資本金　　　　 1,000万円

決算月　　　　 6月

代表取締役　櫻井耕造（前職TIS株式会社）

主要メンバー平見知久（前職TIS株式会社）

主要メンバー　　森未英（前職TIS株式会社）

主要取引銀行　三菱東京UFJ銀行

　　　　　　　千葉銀行

主な業務内容　OTRSの導入、開発、保守サポート

　　　　　　　　　　その他OSSの導入、開発

その他実績　　2013年1月にOTRS AG（ドイツ）とOTRSパートナー契約を締結

　　　　　　　　　2013年1月にサードウェア社とDRBDパートナー契約を締結

2013年8月にプライバシーマーク認定


OTRSとは

・ Open-source Ticket Request System

・ヘルプデスク向けに開発されたチケット管理ソフトウェア

・システムの運用管理を実現するITSM

　　　　> ITIL運用に準拠

　　　　> PinkVerifyにて6プロセス認定されている唯一のOSS

・製品ダウンロード：http://otrs.org/

・独OTRS AG社(フランクフルト市場上場企業)が開発

・開発開始は2001年 – 15年モノ

・OTRS Services are used by 157,830 companies world wide

・AGPLv3(Affero General Public License Version 3)


OSSで実装したITIL運用

運用管理(ITIL準拠)

リリース管理

監視

ZabbixHinemosなど

構成情報収集

構成管理(CMDB)(ITIL準拠)

弊社で実績あるOTRSとの連携の概念図です。

基幹システム


本日のお品書き


リリース管理

監視

ZabbixHinemosなど

構成情報収集


基幹システム

①

②


h7ps://www.otrs.com/company/partnersより

OTRS AGと代理店

弊社は日本唯一のOTRSCertifiedPartnerです


OTRSの適用範囲

サービス戦略

財務管理

投資利益率

サービスポートフォリオ管理

需要管理

サービス設計

サービス・カタログ管理

サービスレベル管理

キャパシティ管理

可用性管理

ITサービス継続性管理

情報セキュリティ管理

サプライヤ管理

サービス移行

移行の計画立案およびサポート

リリース管理および展開管理

サービス資産管理および構成管理

変更管理

サービスの妥当性確認およびテスト

評価

ナレッジ管理

サービス運用

イベント管理

インシデント管理

要求実現

問題管理

アクセス管理

継続的サービス改善

7ステップの改善プロセス

サービス報告

サービス測定

CSI（継続的サービス改善）の投資利益率

CSIに関する事業上の質問

サービスレベル管理

ツールの対応範囲


OTRSの基盤

S/MIME, PGP, HTTPS, IMAPS, POP3S, SMTPS, グループおよび役割に基づく承認コンセプト

ディレクトリ・サービス

§  Active Directory

§  eDirectory§  OpenLDAP

§  Oracle Internet Directory§  DirX Directory Server

§  Sun ONE Directory Server etc.

メール・サーバ

Exchange, Lotus Notes,

Postfix, Sendmail, Exim

プロトコル

SMTP, SMTPS, POP3, POP3S, IMAP, IMAPS

SOAPXML

インシデント管理

ITIL® V3

問題管理ITIL® V3

サービス査定構成管理

ITIL® V3

サービス・レベル合意書

ITIL® V3

変更管理ITIL® V3

データベース・サーバ

§ MySQL

§ Oracle§ MS SQL

§ PostgreSQL

ウェブ・サーバ

Apache, Microsoft IIS

OS

SLES, RHEL, Linux-basierte

Derivate, Windows, MacOS

管理用ウェブ・フロントエンド

ブラウザセルフサービス・ウェブ・フロントエンド

サービス・エージェントウェブ・フロントエンド

構成管理データベース - CMDB / CMSITIL® V3

リクエストフルフィルメント

ITIL® V3

ナレッジ管理ITIL® V3

JSON

ナレッジベース

システム監視顧客調査オープンNMS時間

アカウンティングマスタースレイブ

iPhone 操作

HTTP

Eメール

サポート査定将来的革新カスタマイズされた機能

パブリックウェブ・フロントエンド

オープン・コミュニケーション・プロトコルおよびテクノロジー標準

プラットフォーム独立性市場をリードするプラットフォーム・コンポーネント

セキュリティ標準およびアクセス・コントロール


OTRSが選ばれる理由

Benefits Benefits

Reducecosts(TCO)Savinglicensecosts;reducedleadHme;shortimplementaHoncycle;Supportataffordablecosts

FlexibilityPlaNormindependency;unrestrictedusagerights;openstandards;quickcustomizing.

VendorIndependenceOpenstandards;serviceavailability;investmentprotecHon

MaturityMorethat85,000installaHonswithleadingsoluHonslikeNagios,Apache,MSIIS,MySQL,MSSQL,Oracle,SAPSoluHonManager,Salesforce.com

BusinessServiceAvailabilityConsulHng;Training;Customizing;ServiceSubscripHonandManagedOTRS;globalPartnerNetwork

SecurityEncrypHon:SMIME,PGP,HTTPS,IMAPS,POP3S;Audit:readableSourceCode;Remedial:shortPatchlevelcykles,Access:Groups&Roleconcept

EasyProvisioningofPrototypesRisk-andcostreducHonduringearlyprojectphases

AvailabilityofExpertKnow-HowCost-efficienttrainingofownresources;PlaNormindependency;VirtualizaHon;CommunitySupport

メリットメリット

コスト削減（TCO)

ライセンスコスト削減、リードタイムの削減、実装サイクルの短期化、安価なコストによるサポート

フレキシビリティ

プラットフォームの独立性、制限の無い利用権利、オープン標準、素早いカスタマイズ

ベンダーからの独立

オープン標準、サービス可用性、投資の確実化

成熟性

Nagios, Apache, MS IISm MySQL, Oracle, SAP Solution Manager, Salesforce.comなどの主要なソリューションと共に、15万以上のインストール実績

ビジネスサービス

コンサルティング、トレーニング、カスタマイズ、サービス・サブスクリプション、管理されたOTRS、グローバル・パートナー・ネットワーク

セキュリティ

暗号化：SMIME, PGP, HTTPS, IMAPS, POP3S、監査、公開されたソースコード、救済措置、迅速なパッチレベルのサイクル、グループおよび役割コンセプト

簡単なプロトタイプの展開

プロジェクトの早期フェイズにおいて、リスクとコストの削減

エキスパートのノウハウの利用

自社リソースの対コストの高いトレーニング、プラットフォームの独立性、仮想化、コミュニティ・サポート

ソースコードの変更

機能原理の解析、簡単なカスタマイズ、シンプルなエンハンスメントの交換

透明性およびパフォーマンス

向上されたサービス品質、SLA管理、レポート機能、ケースごとの現状と経過に関する透明性


チケット管理の利用イメージ

OTRS顧客

①メール、Webチケット入力、閲覧

メール回答

担当者

Web回答

②新規チケットの通知

①電話連絡

②Webチケット入力


インシデント管理、イベント管理

情報通知

警告

危険（例外）

記録（完了）

自動で対応

一次サポート

記録（完了）

サービス要求

インシデントの検知

初期の診断

インシデントの調査と診断

高度な専門技術者

復旧策の実施

エスカレーション

問題管理（根本原因究明）

変更管理（通常変更）

記録（完了）

リクエストフルフィルメント

※監視アラートに含めない。

※OTRSから自動起動できないので、実質手動となる。

監視アラート

顧客からのメール

顧客からのTEL

顧客からのWeb入力

【入力】

e-mailチケット

phoneチケット

e-mailチケット

イベントの分類

インシデントの分類

重大性

優先順位付け

エスカレーション


担当者ダッシュボード

チケットを分類して一覧表示

権限のあるチケットのみ表示

簡易サマリ


チケット画面

対応履歴自動振り分け

チケット番号の自動採番

管理情報は追加可能

SLAに基づく初回応答期限返答期限解決期限


新規メールチケット(1)

OTRS内の顧客マスタから引用

SLAに応じた応答期限設定


新規メールチケット(2)

項目は追加可能


その他チケット管理機能

＜イベント管理、インシデント管理、要求実現、問題管理＞　・チケットの管理項目をカスタマイズ

　・入力必須、入力チェック

　・チケットの更新履歴管理

　・チケットのロック

　・チケットのキューをエスカレーション

　・カレンダー、営業時間の設定

　・新規メールチケットの自動返信

　・返信テンプレート

　・チケットの統合、分割

　・チケット間、FAQ記事、CI、変更依頼書などとリンク

　・SLAの定義

　・ステータス遷移の定義

　・優先度の定義

　・複数の管理画面の作成

　・チケットを検索

　・チケット・アーカイブ

　・業務プロセスを作成　　　　


OTRSプロセス管理

＜ビジネス・プロセス管理(ワークフロー)＞・業務プロセスを以下のように定義し、運用に必要な業務を管理・OTRS管理画面(Web画面)上で作成・変更可能


アプリ面から見たOTRS

・バニラ状態は比較的シンプル・設定項目3,000 over・ (残念ながら)ドキュメントが追いつききれてない・コミュニティのサポートが機能しきれてない

アプリだけでもかなりカスタマイズ可能設定見つけるのは大変かも


技術面から見たOTRS

・ Apache + mod_perl　　→ 枯れた技術を採用(15年〜)　　　　　　→ 安定性は問題なし　　→ perlなのでブラックボックスは存在しない(できない)　　　　　　→ソースを見れば動きが一目瞭然

　　　　　　→カスタマイズも容易・独自のMVCフレームワーク　　→ Webアプリケーションとしてはセオリー通りの作り　　　　　　→ モジュール化されており変更に強い　　→ 画面層のテンプレート化　　　　　　→必要ならカスタマイズ可能

　　→ APIを使用してほぼすべての画面操作をプログラム可能・機能拡張用のフック多数　　→ 本質的にソースを読んで機能拡張ができる前提で設計されている・データモデルはもう少し頑張りましょう

　　→ 過去の互換性や柔軟性を考えると止むをえないところはある

ちょっと古臭いし言いたいこともあるが押さえるべきところは押さえてある


OTRSの内部アーキテクチャと連携ポイント

API層

ビジネスロジック

DB

コントローラ層

HTMLテンプレート連携

PG等

SOAPREST

連携PG等

データ移行(初期投入)

BI等

CSVインポート/エクスポート

イベントトリガ

連携PG等


カスタマイズ例１

メール送信前にワンクッション入れたいOTRS標準: 送信ボタンを押したら送信要件:　　　　確認画面を経由してから送信背景:

　　　　　取り扱う情報の関係で誤送信に関しては通常以上の配慮を促したい

テンプレート・コントローラの一部を修正し、送信前確認画面を追加


カスタマイズ例２

SLA上の対応時間の計算がOTRS標準とは違うOTRS標準: チケット状態に関わらず時間を消費要件: お客様起因での対応中断中は時間消費と見なさない背景: サポートサービスを提供している会社の事例

　　　　　SLAは契約上の定義のため、OTRS標準に業務を合わせた場合、　　　　　再契約の発生等影響が甚大

ビジネスロジックの一部をカスタマイズSLA対応時間を要件ベースに修正


カスタマイズ例３

顧客画面で一部アクセス権限を特殊なものとしたいOTRS標準: 同一会社内のチケットはすべて見える要件：特定の種類のチケットについては同一会社内でも見えないようにしたい

背景: フランチャイズチェーンでの事例。本部とFCとのやりとりにOTRSを使用　　　ハラスメント報告など、FC責任者に報告内容が見えることにより報告者が不利益を　　　被る可能性がある

チケット変更時のトリガーを使用することにより権限を書き換えて対応


商用プロダクトと比べた場合

・安定度・機能面からはほぼ問題なく業務が乗るレベル・足らない機能・欲しい機能がないわけではない　　　→ 商用プロダクトでも本質的には同じ　　　→ 使い方で回避しますか？業務を変更しますか？ + カスタマイズを入れますか？

・ブラックボックスなし　　　→ (ソースが読めれば)カスタマイズ可能　　　　　　　　あとはコスト見合い　　　→ 細かい挙動についても追跡可能　　　→ 外部との連携等を考えると制約が少ない/明確化しやすい

ソースが公開されていることと相まって業務要件への対応性が非常に高い


本日のお品書き


リリース管理

監視

ZabbixHinemosなど

構成情報収集


基幹システム

①

②


リリース管理とは

変更管理で承認された作業依頼書(RFC)に対する変更を、適切に実施されたかを管理すること従って、リリース管理で重要なのは正確な手順とその遂行

＜リリース管理を自動化するメリット＞①変更作業のコスト削減（作業要員の負荷軽減）②属人化の排除（特定要員への依存の排除）③ヒューマンエラーの排除（オペレーションミス防止）

最近では、ChefやAnsibleで自動化することが多い


成功するリリース管理の自動化とは

全ての変更をいきなり自動化するのは現実的ではない

＜効果ある場合＞・手順の内容が毎回同じであること・頻度が多い・時間がかかる等、コスト要因となっていること


OTRSと連携することのメリット

・履歴管理の集約　　　どのリリースでどのチケット(サービス要求)を満たしたのか　　　構成管理と連携することによる影響範囲の明確化・内部統制　　　プロジェクト責任者による承認の記録　　　ステークスホルダーとの情報の共有・連絡


なぜJobScheduler?

・将来リリース手順の変更が発生する可能性がある・将来適用範囲を広げていくことが想定される・指定時間でリリースを開始したい・処理の進行状況などを確認したい

・失敗時の再実行を行いたい・複数のサーバで順番に処理を実行したい・なるべく低コストで

管理UIやエンジンを新規開発するのはナンセンス！

JobSchedulerでほぼやりたいことは満たせる


リリース管理の例

・リリース = ジョブチェーン・各手順 = ジョブ・既存の作業手順書・スクリプトを解析し、ジョブチェーンとして再構成・ジョブチェーンの実行が完了 = リリース完了

リリース物の確認

リリース物取得

切り戻し準備

リリース物転送

リリース物展開

実行結果のOTRSへの反

映


OTRS+JobSchedulerの自動化の仕組み

起票

変更起票者

運用管理サーバ

リリース対象サーバ

リリースサーバ

承認完了

バッチを実行

ジョブチェーン投入(スケジューリング)

変更の承認

変更の承認依頼

変更依頼を起票

変更管理者

実行結果、OTRSステータスを更新

変更の完了メール送信

<前提>バッチの実行は、リリース対象サーバにJobSchedulerエージェントか、PowerShellのインストールが必須となります。

sh,bat,exeなどのバッチ

JobSchedulerに登録されているジョブ


OTRS変更管理の自動化フロー

・プロセス管理の機能で、変更管理を実装


リリース申請を起票


リリース申請を依頼、承認

＜ここから承認者の操作＞

JobSchedulerへジョブチェーンを投入（自動実行のスケジューリング）


ジョブが全て完了

ジョブが全て完了したら、OTRSのステータスを更新して、実行結果を反映させる。


リリース管理自動化のキモ

作業手順の曖昧さの排除

「正しくXXされたこと」ステータスコードやチェックサム等、プログラムへの落とし込みが必要

既存のリリースバッチ等の修正が必要な場合が多い

　　　　　　　

ブラックボックス化した作業手順についてはコード解析や手順の精査が必要



Windowsは要注意

リモートで制御する場合には構成を考える必要ありPowerShell, WinRMドメイン/Workgroup等による認証認可に対する確認

GUI管理ツールの壁

権限や構成(設定)等、手を入れる必要があるケースがほとんど

コマンドラインへの置き換えが可能かどうかが鍵



ネットワーク構成

通常本番機との間にはFWがあり、管理用端末のみアクセス可能としていることがほとんどOTRS, JobScheduler等各コンポーネントの配置は処理分散配置上要注意

ガバナンス・社内規約などとの調整がほぼ必須


まとめ


OSSツールは商用製品に追いついたか？

ある意味ではYes, ある意味ではNo

OSSでやらなければ「ならない」→ ナンセンスOSSは検討から「除外する」→ナンセンス

機能実績サポート体制….

業務が乗るか業務が回せるか

OSSでも業務が乗って回せるものはある商用でも業務に合わなければ無意味

×玉石混交なのは確か　　→商用製品でも…　　→作っている過程がオープン○OSSであることのカスタマイズ性

個別に回答を出すべき1候補として評価・検討する意味はある銀の弾丸は存在しない

＝


おまけ


OTRS最新動向

OTRS 5s がリリース準備中！(2016/11/1)　　・スケジュール管理/リソース(要員)管理機能の強化　　・メール暗号化周りの機能強化　　機能詳細は今後随時発表されます

OTRS4のコードメンテナンスはOTRS6のリリースまで継続

OTRS6については公的にはNo plan らしい..


弊社のOTRS導入支援サービス

コンサルティング

要件定義

設計

導入

開発〜テスト

移行

運用・保守

弊社がお手伝いできる範囲

•  要件に応じた他ツールのご紹介・導入支援

•  Fit&Gapの分析・利用業務イメージの策定

•  OTRSインストール・初期設定(AWS,Azure,オンプレ)

•  OTRS設定項目の決定・設定実施•  各種手順書作成

•  カスタマイズ機能の開発•  他システムとの連携開発

•  Excel/既存システムデータのクレンジングと初期投入

•  OTRS保守サポート(問合わせ)•  運用支援(設定変更や障害対応等)•  バージョンアップ

ソー

ス解析・O

TRSAG

へのフ

ー

ドバ

ク


OTRSお試し

・OTRSインストール済みのDockerイメージをDocker Hubにて公開しています。・Dockerが利用できる環境(AWSやさくらインターネットなど)がご容易できる方はインストール不要で評価が可能です。DockerHubにて “otrs5”にて検索ください。

最新情報やOTRS機能の紹介などを弊社HP・ラボノートにて鋭意行っております。Googleにて”OTRS”で検索ください。


ご清聴ありがとうございました。

おわり

otrs x jobschedulerでリリース管理 - 20160912セミナー資料

Technology