Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (19)
Semelhante a 運用現場の過去、現在、未来
Semelhante a 運用現場の過去、現在、未来 (17)
運用現場の過去、現在、未来
- 1. 運用現場の現在・過去・未来 ∼ オレ達の明日はどっちだ ∼ 波田野 裕一 （日本UNIXユーザ会) odstudy #1 2011-07-22
- 5. ‣ サービスの安定 社会基盤に相応しい安定運用 ‣ 業務負荷が平準的 個々人ががんばりすぎなくても業務が回る運用現場 ‣ 運用に対する評価が適正 適正な利潤を生む現場と、適切に評価される要員 運用現場の理想 安定した運用 楽な運用 稼ぐ運用
- 7. ‣ サービスの安定 社会基盤に相応しい安定運用 ‣ 業務負荷が平準的 個々人ががんばりすぎなくても業務が回る運用現場 ‣ 運用に対する評価が適正 適正な利潤を生む現場と、適切に評価される要員 運用現場の実際 安定した運用 楽な運用 稼ぐ運用 トラブル多発 高負荷/属人的 コストセンター/ コストカット
- 8. 運用現場における典型的な声 (1) ✓ 業務が多岐に渡り、全てを把握することが困難になっている。 ✓ 業務の設計思想が失われていて、すでにどうにもならない? ✓ ドキュメントが整備されていない。あっても更新されていない。 ✓ どんなドキュメントが必要なのかがわからない。書き方がわからない。 ! ✓ 一部の人間にしかできない業務があり、業務が集中している。 ✓ 属人化が進み、ノウハウの継承ができていない。 ✓ 異動により現場が混乱することが多い。 InternetWeek 2009 発表資料 より
- 9. 運用現場における典型的な声 (2) ✓ 人が育たない。優秀な人が入ってこない、定着しない。 ✓ がんばっても評価されない。 ✓ 業務や現場自体が評価されている実感がない。 ✓ 運用作業やトラブルが多く、前向きな改善に着手する余裕がない。 ✓ ツールが使いにくいが、改修にはコストと期間が必要なため我慢して 使っている。 ✓ 新規のツールを設計したいが、どんな要求があるのか現場でもわかっ ていない。 InternetWeek 2009 発表資料 より
- 10. 運用現場における典型的な声 (3) ✓ サービス設計導入時の検討漏れや実装が間にあわない部分を「運用でカバーする」 など設計側のその場しのぎの影響を直接受ける。 ✓ 個別に対応しすぎて、全てが特別対応に等しくなっている。 ✓ 依頼されてから動き出すまでのリードタイムが長い。 ✓ 声の大きいユーザが強く、必要以上のサポートを強いられる。 ✓ コスト削減要求が強いが、どう効率化すべきなのかが見えない。 InternetWeek 2009 発表資料 より
- 12. 運用現場の諸問題 1. 高負荷 2. 属人的 3. 見えぬ費用対効果 ブラックボックス化 低付加価値化 業務が複雑化 「費用」は一定で「効果」は経年劣化する 「費用対効果」は勝手に低減していく 現場では制御不能状態
- 17. 運用現場 +「運用でカバー」 1. 高負荷 2. 属人的 3. 見えぬ費用対効果 resource 業務ブラックボックス度 Up! 低付加価値度 Up! 業務複雑度 Up! 運用業務の 「見えない化」促進
- 22. ! 来たるべき世界 未 来
- 23. クラウドに吸い込まれる運用現場 尖ったモノを持つ「攻める」運用現場 変化に柔軟に対応高度な専門性 短納期/スピード 費用対効果が明確 スケーラビリティ スティッキー 一般的な専門性 硬直的 意思決定に時間 どんぶり勘定 高コスト体質 非合理的 二極化する運用現場
- 24. Platform as a Service Service as a Service Infrastructure as a Service SaaS PaaS IaaS 発展形 納期/コスト削減効果 大 多様な要求、変化が激しい 要求が比較的画一的 普及? 消えるインフラ運用
- 26. 専門性からみたTier Tier 1 Operator Tier 2 Operator Tier 3 Operator 単価の安い単純仕事 Scalability 単価の高い高度仕事Proffesionalism 中途半端 ニッポン 運用でカバー
- 30. 運用現場の現在を みつめよう 現
- 35. 今年は運用ドキュメントが熱い 2010年11月 手順書友の会 発足 (JANOG系) 2010年12月 jus勉強会 ドキュメントを作りたくなる魔法のツール Sphinx ひとりSphinxな人出現 (@togakushiさん) 2011年 6月 odstudy 発足
- 36. 道具もそろってきた いいバージョン管理システム Mercurial 手順書のための構造化言語 構造化記法 reST + ドキュメントプロセッサ Sphinx 決め手!! 手順書管理媒体 バグトラッキングシステム Redmine + リポジトリ連携 blockdiagシリーズ (世界の小宮さん)
- 38. おまけ: ITIL v3では物足りない ITIL v3の大きな特徴は、ServiceTransitionの 概念の導入かなと。 ITサービスのライフサイクルという概念は、 意外と良いたてつけかも。 しかし、ServiceOperationの内容は粗い印象。 ※個人的な認識です:-)
- 40. ‣ 「コストセンター」からの脱却 ‣ 「運用品質」の正常化、適正化 ‣ 「運用でカバー」は最後の最後の手段 運用現場に求められる視点 1 「運用設計」の重要性高まる 「費用対効果」との闘い
- 41. 会計上、運用は「コストセンター」 会計上の論点 財務会計: 損益計算書 売上高 売上原価 売上総利益 販売費及び一般管理費 営業利益 収益部署 費用部署 販売部門 製造部門 サービス運用部門 事務管理部門 IT費用のほとんどは間接費 (売上と直接関連付けできない) ITの普及により、企業における費用の 間接費比率が過半以上に 売上原価とならず、共通配賦となる = コストセンター (= IT) 財務会計上、運用はコストセンターである 「コストセンター」 からの脱却
- 43. 会計上、運用は「コストセンター」 会計上の論点 企画部門 販売部門 開発部門 設備部門 運用部門 +資産(商品) | -資産(現金) 仕訳による表現 (借方 | 貸方) +資産(無形固定資産) | -資産(現金) +資産(売掛金) | +収益 | - 資産(商品) +資産(有形固定資産) | -資産(現金) +費用(間接費) | -資産(現金) 費用部署 収益部署 製造 資産化部署 費用部署 +費用(間接費) | -資産(現金) +費用(直接費) | -資産(現金) +費用(直接費) | -資産(現金) 製造 仕訳上も、運用はコストセンターである 「コストセンター」 からの脱却
- 44. 過剰品質による、運用の「高コスト体質」 品質上の論点 期待と能力の均衡 高品質 (Q) 低料金(C)短納期(D) 能力 リソース(=人数x時間) + 設備 ! レーダチャートの各軸を明確にする or いずれかの軸を減らすこと! により、コストの適正化がはじめて可能となる。 「運用品質」の 正常化、適正化
- 45. 製品の歩留まりが品質ベンチマーク 加工 出荷原材料 製品 商品 不良品が 多い? 製造工程 に問題? 原材料に 問題? 調査検査 QC7つ道具 原価計算ISO9000 サプライチェーン 製造業には生産工学による品質基準が発達している。製品の歩留まり が品質ベンチマークとなる。 品質の定義、基準が曖昧 品質上の論点 「運用品質」の 正常化、適正化
- 46. 過剰品質による、運用の「高コスト体質」 「顧客満足度」という不確かな品質ベンチマーク サービス リソース 集約 サービス 運用 提供 もやっと満足 なんとなく不満 もやっとうまくいっ ている なんとなく不調 満足 わりと丼勘定 無形性 / 生産と消費の同時性 / 不均質性 / 消滅性 (作り置きができない) サービス業には、サービス工学に該当するものがなく、顧客満足度と いう曖昧な基準しかない。 品質の定義、基準が曖昧 品質上の論点 「運用品質」の 正常化、適正化
- 50. ‣ 業務フレームワークを作り上げること ‣ 客観的、論理的、科学的な論拠 ‣ 改善のサイクルが無理なく組み込まれる 運用現場に求められる視点 2 「モデリング」の重要性高まる 「運用設計」の視点 最後に
- 51. 運用設計の目的 1. 高負荷 2. 属人的 3. 見えぬ費用対効果 運用現場の現実 ブラックボックス化 低付加価値化 業務が複雑化 1. 業務の複雑化を許さない仕組み 作り 2. 業務のブラックボックス化を許 さない仕組み作り 3. 業務価値の陳腐化を許さない仕 組み作り 運用設計の目的運用現場の理想 ‣ サービスの安定 社会基盤に相応しい安定運用。 ‣ 業務負荷の平準化 うまく業務が回る運用現場。 ‣ 運用に対する評価の適正化 適正な利潤を生む現場と、適切に評価される要員。 1.「運用」への期待の明確化 3. 期待に対する消費リソースの測定化 2.「運用設計」の確立 常にシンプル 常に見える 常に価値を生む
- 56. 実働業務の分類 手順書 発生予測 発生起因 定時作業 有 計画ベース 内部 申請作業 有 実績ベース 外部 インシデント 有 不可能 外部 イレギュラー 無 不可能 外部 定時作業 申請作業 緊急作業 属人作業 高度 初歩 定 常 非 定 常 スピード / ユーザビリティ / スケーラビリティ / 低コスト
- 57. 運用組織 (監視 チーム) 監視チーム! サービス監視! 検知通知、情報収集 作業種別 手順書 有無 外部/ 内部 作業項目 定時作業 有 内部 監視待機 緊急対応(外部) 有 外部 検知情報の登録 緊急対応(外部) 有 外部 検知情報の更新 緊急対応(外部) 有 外部 検知情報の他部署への報告 (発生/中間/復旧) 緊急対応(外部) 有 外部 他部署からの監視調査依頼 (定型) 緊急対応(外部) 有 外部 情報収集 (他部署の動向/サービスの状況) 緊急対応(外部) 有 外部 顧客停止情報の登録 緊急対応(外部) 有 外部 顧客停止情報の更新 作業カタログ 正しい状況把握 と情報伝達! の専門職 ドキュメント スキルセット ツール
- 58. ‣ 「システム」(道具)のお守りからの脱却 ‣ より「サービス/業務」に近い立ち位置へ ‣ QCD(品質、コスト、納期)による評価へ 運用現場に求められる視点 3 「業務知識」の重要性高まる 「サービスデリバリ」の視点
- 59. 「おもてなし、付加価値」仮説 サービス提供 「お役所仕事」 ある ない おもてなし Service とは である。 運用がサービスデリバリなら、 「おもてなしの提供」であり、 コストセンターじゃない!、と言えるはず 付加価値