クラウド時代にこそ求められるIt部門の役割
•
4 likes•2,378 views
「クラウド時代にこそ求められるIT部門の役割 ～サービスカタログによるITサービス提供～」というタイトルで、2015年10月から継続的に実施しているセミナーの資料です。
Recommended
More Related Content
What's hot
What's hot (20)
Similar to クラウド時代にこそ求められるIt部門の役割
Similar to クラウド時代にこそ求められるIt部門の役割 (20)
クラウド時代にこそ求められるIt部門の役割
- 2. 2 自己紹介 Microsoft AzureやWindows Serverを活用した ハイブリッドクラウド基盤の計画、設計、導入に従事。 名前： 大井 雄介 所属： 日本マイクロソフト株式会社 エンタープライズサービス部門 タイトル：シニアコンサルタント Mail： yooi@microsoft.com
- 4. 4 現実：IT予算は年々IT部門から業務部門にシフトしている IT部門がすべてのIT予算を管理するケースは年々減少。 一方で、業務部門独自のIT予算がますます増加。 出典：ガートナープレスリリース「ガートナー ジャパン、2015年度国内IT投資動向を発表 2015年度もビジネスの「成長」「変革」のためのIT投資が増加する傾向は変わらない 一方で、IT部門が把握していないビジネス部門によるIT投資の存在も浮き彫りに」 2015年3月3日 https://www.gartner.co.jp/press/html/pr20150303-01.html 56.8% 59.7% 63.5% 13.5% 15.6% 13.1% 21.5% 17.9% 16.9% 8.2% 6.9% 6.5% 0% 20% 40% 60% 80% 100% 2014年11月調査 2013年11月調査 2012年11月調査 IT総予算における利用部門が管理する予算状況 利用部門が管理するIT予算は存在しない (すべてIT部門が管理) ある程度利用部門が管理している IT部門が管理・把握していない利用部門独自のIT関連予算が存在 利用部門に独自のIT関連予算が存在するか否かも不明 認証番号：「GJ15421」
- 5. 5 クラウド活用のワーストケース＝「シャドーIT」の末路 各部門が個別に最適なクラウドソリューションを選択した結果として… 個別の認証システム バラバラの アーキテクチャ 部署ごとの発注 • システム間連携できず、業務がサイロ化してしまう • 多様すぎるテクノロジーに対応できない • 個別調達で結局コストが増加している • 正確なIT費用の全体像がよくわからない • ID/パスワードは毎回入力が必要 • セキュリティポリシーもシステムごとにバラバラ
- 6. 6 振り返り：エンドユーザーコンピューティングの教訓 • 業務の現場にITが浸透 • ITのダウンサイジング加速 • コストダウン、スピードアップ • 社員のITリテラシー向上…など 管理者不明の野良サーバーが床に放置 セキュリティ対策なし、バックアップなし Active Directory乱立 IT部門がAD統合・仮想化集約で巻き取った…。 あの苦労を繰り返さないように！ 部門ファイル サーバー 部門グループ ウェア VB/Accessでの 業務アプリ開発 業務とITに多くのメリットをもたらした 一方で様々な課題も…
- 7. 7 クラウド時代にはIT部門は本当に不要になるのか？ 旧態依然としたIT部門は不要になる。一方で、個別最適でのクラウド利用も間違いなく問題を引き起こす。 クラウドファーストの時代には、IT部門に新しい役割が求められる。 クラウドへの無関心・抵抗 (シャドーITの蔓延、IT部門不要論に拍車) クラウドブローカー 全社のクラウド契約や管理作業をIT部門でとりまとめる。 クラウドアドバイザー 最新技術動向を理解し、自社に最適なクラウドサービスを 業務部門に推薦する。 クラウドプロデューサー クラウドサービスを「素材」として、必要な機能やサービスを 付加し、自社にとっての最適なサービスを組み上げる。 クラウド理解度・活用度 ここを目指す！ クラウド時代に求められるIT部門の役割
- 8. 8 サービスカタログ サービスカタログとは、サービス提供者が提供する様々なITサービスをメニューとして一覧化したもの。 サービス提供者は、サービスの実現手段となる構成要素をとりまとめ、利用者にサービスを提供する。 サービス利用者は、サービスカタログの中から必要なサービスを選択し、利用する。 サービス利用者 サービスを構成する要素 Linux 仮想マシンサービス Windows 仮想マシンサービス データ分析基盤サービス ファイルサーバーサービス クラウド認証基盤サービス モバイル端末管理サービス ・ ・ ・ Hyper-V サービスカタログ 運用システム・プロセス パブリッククラウドリソース Microsoft Azure 物理サーバー オンプレミスリソース サービス提供者 System Center 2012 R2 各種運用管理ツール ヘルプデスク SEサービス 変更管理 障害監理 Linux 仮想マシンサービス Windows 仮想マシンサービス その他の パブリック クラウド その他の 仮想化基盤
- 9. 9 振り返り：古くて新しいテーマ - サービスカタログ 以前からサービスカタログの意義や考え方自体は幅広く議論されていた いま、ハイブリッドクラウドが当然の時代になり… • マルチベンダー・マルチクラウドによりますます多様化するテクノロジー • 常に進化し続けるクラウドサービス • 日に日に高まるセキュリティ・コンプライアンスの重要性 • ビジネスが要求するスピードが格段にアップ サービスカタログの必要性が今ますます高まっている
- 11. 11 サービスカタログの構成要素 (サンプル) エコノミー スタンダード プレミアム 監視 なし 9-18 24x365 バックアップ なし 日次 4時間毎 災害対策 なし あり あり 問題切り分け なし なし あり サービスカタログ サービスメニュー Windows 仮想マシンサービス リソースパターン サービスクラス サービス定義サービスオプション • 運用サービスの品質レベル• CPU/メモリなどのリソース量 • サービス内容のより詳細な定義 サービスに含まれる・含まれな い事項 利用者・提供者それぞれの責務 制約事項 価格・課金に関するルール • サービスに付加するオプション アンチウィルス導入 パッチ管理 バックデータのリストア アプリケーション脆弱性診断 コア メモリ ディスク Ｓ 1 2 GB 100 GB Ｍ 2 4 GB 200 GB Ｌ 4 8 GB 400 GB XL 8 16 GB 800 GBサービス選択ガイド • SQL Serverをインス トールする場合は、少 なくとも”L”以上のリ ソースパターンを選択 すること。 • 本番系システムでは、 少なくとも”標準”以上の サービスレベルを選択 すること • ・・・・・
- 12. 12 サービスクラス一覧 エコノミークラス スタンダードクラス プレミアムクラス 仮想マシンとして動作させるために必 要な最低限の運用サービスのみを実装 したクラス 本番システムとして一般的に必要とさ れる運用サービスを実装したクラス 業務上重要度の高いシステムに必要な 運用サービスを実装したクラス 監視 監視設定なし 領域/死活/パフォーマンス監視 監視項目数：30項目まで 領域/死活/パフォーマンス監視 + OS/ミドルウェア/ソフトウェア監視 監視項目数：60項目まで バックアップ なし なし バックアップ + リストア対応あり (月○回のリストアまで可能) 障害対応 なし なし OS 障害対応を実施 ウイルス対策 あり あり あり 提供成果物 なし なし 障害報告レポート(月次) 月額 x,000 円/インスタンス xx,000 円/インスタンス xx,000 円/インスタンス サービスクラス＋サービスオプション 運用サービスをクラス分けして定義する。 開発環境、本番環境(一般)、本番環境(基幹系)の3段階が一般的。 クラス分けに適さない項目を「オプション」として定義するのも常套手段。 SAMPLE
- 13. 13 サービス定義 提供するサービスの具体的な内容を定義する。 特に、何を提供し、何を提供しないのかの明確化が重要。 ここで定義したサービスをきちんと利用できるような機能やインターフェースを用意する必要がある。 特にインターフェースのところが意外とおろそかになりがち。 例：ユーザーに仮想マシンの起動停止をさせるのであれば、ポータルへのアクセスやスクリプトが必要。またそのため の認証基盤が必要。そのためのID登録、パスワードリセットなどの仕組みが必要…。 サービス概要 Microsoft Azure で稼働する仮想サーバーおよびそれに対する運用サービスを合わせて提供する。 要件に応じて、リソースパターン(仮想マシンサイズ)および運用サービスレベルを選択できる。 利用可能なOS • Windows Server 2012 R2 • Windows Server 2008 R2 基本的にすべて英語版。日本語化が必要な場合は、別 途提供するスクリプトを用い、利用者側で設定する。 オプションサービス 以下の運用サービスを選択可能。詳細は別紙。 • バックアップ/リストアサービス • 災害対策サービス • セキュリティチェックサービス サービス成果物 • Azure 仮想マシンおよびその運用環境 • 月次利用報告レポート • 障害報告レポート サポート体制 以下の体制でサポートを提供する。 • 形式：メール • 時間：平日 9:00～19:00 制約事項 • AzureおよびOSレベルの問題判別はサービスの範 囲内(ただしサービスレベル「標準」以上) • アプリケーションやミドルウェアの問題判別は利用 者の責務 SLA • Azure仮想マシン自体のSLAはAzureの標準のSLA に準ずる • 運用サービスに対するSLAは定義しない 解約 解約については○か月前までに通知すること。 • ・・・・ SAMPLE
- 14. 14 サービスカタログにはSLAを記述するべきか？ 「サービスカタログにはSLAを記載するべきである」と考える人は多い。 特に外販をしたり、社内であっても課金をする場合には。 トップダウン 過去の実績とマーケティング視点を踏まえて決定した数字 サービス構成要素の稼働率目標(実績)をもとに算出した数字 SLAは稼働率目標ではなく、稼働実績の目安でもない。あくまで契約上の取り決め。 ボトムアップでのロジカルな算出は現実的には困難。定義するならトップダウンで決める。 ボトムアップ SLA クラウドサービスSLAの決め方には2種類ある
- 16. 16 「粛々と運用する」というフェーズはもう存在しない クラウド利用において求められる運用フェーズ 新機能が数か月～数週間ごとにリリースされ、利用している環境で即利用可能な状態になる。 サービス内容・品質の改善やアーキテクチャの見直しを継続的に行うことが求められる。 自ら最新情報にキャッチアップし、自ら利用方針について判断していく必要がある。 設計・構築 運用 設計・構築 運用 設計・構築 運用 オンプレミスにおける一般的な運用フェーズ ベンダーに設計・構築を依頼、一度サービスインした後は基本的に手順にのっとって粛々と運用を行う。 製品バージョンアップは数年に一度。 「このバージョンは導入を見送る」という判断もありうる。 新機能リリース新機能リリース 新機能リリース 新機能リリース 新機能リリース アーキテクチャ見直しサービス改善 アーキテクチャ見直しサービス改善 新バージョンリリース新バージョンリリース サポート切れが近いから バージョンアップせねば このバージョン は見送ろう…
- 17. 17 クラウド利用において求められるロール クラウドサービスアーキテクト オペレーター クラウド技術スペシャリスト 利用者 • ユーザーからの一次問い合わせ窓口 • ルールにのっとった運用を行う • クラウドサービスを利用する • サービスカタログの策定や更新 • 新技術の調査、取り込み方針の検討 • 社内ルール、組織体制の検討 クラウド技術に関する幅広い知識 ITサービスマネジメントについての知見 • 利用者への設計アドバイスやQ&A対応 • トラブル対応（ベンダーサポートとの連携) • 新技術の詳細な調査、検証 クラウド技術に関する深い知識 新技術を自主的に学び続けるマインド どんどん機能が変化する クラウドの世界においては、 オペレーターも「手順書通りの操作」 だけでは対応しきれない。
- 18. 18 オンプレミスとパブリッククラウドの違い オンプレミス クラウド バージョンアップ 数年に1回 1年に600以上の新機能リリース 一度構築した後は、機能は変わらない 利用している環境に新機能がどんどんリリース 一度構築した後は、UIは変わらない UIもどんどん変化していく 運用 構築フェーズで作ったシステムを粛々と運用 運用フェーズにおいても環境はどんどん変化する (変化することが求められる) 全てのオペレーションが自社で可能 一部のオペレーションはクラウド事業者に依頼 障害対応 対象はすべて手元にあり、自社で調査・対応できる クラウドサービス内部の調査・対応はクラウド事業 者に依頼が必要 足りない機能 標準機能でできないことは、作りこみで対応 しばらくすると新機能としてリリースされる (かもしれない)
- 19. 19 さらなるカタログ化・標準化へ アーキテクチャ標準化 関連する業務プロセス標準化 • 標準的なシステム構成についてはリファレンス アーキテクチャを定義、参考価格も提示する。 「リファレンスアーキテクチャに沿った構成 であれば、より短納期で提供できますよ！」 • セルフサービスポータル＋バックエンド処理 の自動化が理想形。 • 「費用見積もり＆承認」から「価格提示＆課 金管理」という考え方へ。 • CPU・メモリは後から変えられるので、性能 見積もりに時間をかけすぎない。 • ただしストレージ性能については事前に十分考 慮すること！
- 20. 20 クラウド活用のためのITサービス具現化ステップ まず基本方針に基づいてサービスカタログを定義し、それを実現するためのヒト・モノ・プロセスを明確化していく。 このステップは一度きりのウォーターフォールではなく、繰り返し継続的に実施する。 まず開発用途向けにスモールスタートし、テストや本番用途向けに拡大していく、というのもお勧め。 1. クラウド利用基本方針 • クラウド利用の目的/KPI • スコープ (開発/テスト/本番) • サービス要件 (セキュリティ、 課金、サポート) 2. サービスカタログ定義 利用者視点で以下を明確化 • 利用できるリソースの種類 • 制約・禁止事項 • 利用手順 • サポート内容 • 費用 • SLA • など 3. ヒト • 組織とロールのマッピング • 必要なスキル 4. モノ • 全体アーキテクチャ • 運用管理システム要件 5. プロセス • 利用手順 (利用者視点) • 運用手順 (管理者視点) • 社内ルール • 運用手順書の策定 ～テスト • ルールの策定 • 体制づくり • トレーニング • システムの設計 ~実装
- 21. 21 [ご紹介]マイクロソフトが提供するコンサルティングサービス マイクロソフトのコンサルティングサービスがお客様とのディスカッションを通じ、まず「仮想マシンサービス」など の代表的な1つのサービスについて、お客様と共同でサービスカタログを作成します。 サービスカタログの策定には、最新クラウド技術の知識と、ITサービスについての知見の両方が必要になります。ぜひ マイクロソフトのコンサルティングサービスにお任せください。 現状確認 ドラフト版作成 ディスカッション 最終版ご提出 現状のサービス、システ ム、課題を整理します。 ドラフト版となるサービス カタログをMSが作成しま す。 お客様とのディスカッショ ンを通じて、ドラフト版を ブラッシュアップします。 最終版のサービスカタログ およびその他ドキュメント をご提出します。 合計5回のお打ち合わせを1か月程度で実施 SA(ソフトウェアアシュアランス)のお客様は、本サービスをその特典であるAZDPS(Azure計画サービス) としてご利用いた だくことも可能です。 進め方 成果物例 仮想マシンサービス サービスカタログ リファレンスアーキテクチャパターン サービス選択ガイド 補足 サービスカタログ策定支援サービス 全体システム概要アーキテクチャ ・・・具体的な成果物内容はご相談のうえ決めさせていただきます。
- 23. 23 © 2015 Microsoft Corporation. All rights reserved. Microsoft, Windows, Microsoft Azure and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION