運用で失敗しないために 後半

●よくある失敗例1 運用設計の不備
プロジェクトにおいて、構築側と運用側のメンバーや会社が異なる場合、
運用引継ぎが発生します。

このとき、どうしても期限が切られている構築側とこれから長い航海に出る運用側では、
意識や優先順位が異なり、その穴を埋めるためにも運用設計が必要なのです。

タイトなスケジュールで作り上げるの構築側と、安定した船出を求める運用側、
なかなか意識の差ははげしいものがあります。
極端な話、頭の中はこのような状況でしょうか。

構築側:「運用のことは運用ベンダが考えるだろう。とにかく構築を終わらせなければ。」
運用側:「きちんと所定の情報をインプットしてくれなければわからない。こうしたことは考慮されているか?」

構築側と運用側、どちらになにを期待するのか、しないのか、
役割分担、作業範囲、理想の運用の姿、過渡期の姿・・・
ある程度の共通認識をもって本稼働に挑むのとそうでないのとでは、稼働直後のシステム安定度に大きく影響します。

●よくある失敗例2 分業による管理コスト上昇
システムは多くの技術要素から成り立っています。
ITILのサービスカタログという考え方で表現してみるとわかりやすいのですが、
サービス視点でシステムを整理していみると、登場人物(担当者/会社/体制/チーム)の多さに驚きます。
OS、ミドルウェア、DB、H/W、アプリケーション、ネットワーク、セキュリティ、監視通知、
アプリ運用、プログラム保守、ワークフローシステム、会計システム、BIシステム、パソコン・・・

一昔前はシステム運用といえば、大手1社に丸投げしてしまうケースが多かったのですが、
オープン化や統制の強化の流れを経て、ユーザ自らがこれらを主体的に管理するという考えが広まりました・

もちろんユーザ自らが主体的に運用に参加することは当然ですし、全く異論の余地がありません。
しかし。主体的な参加と、自身で抱え込んでしまうことは違います。
これだけの技術/サービス要素が分散していると、なかなか管理をしきれるものではありません。
その結果、せっかくひとつひとつ、サービスを比較してコストが安い体制をとったにも関わらず、
社員のサービス残業として見えないコストになっていることが少なくありません。
このお話、情報システム部門の課長さんにはだいたい「うんうん」と頷いていただけるのではないでしょうか。

仮にひとつひとつのベンダコストは安くても、これらを管理するユーザやシステム部門の工数が膨大になってしまう、
というわけです。

●よくある失敗例3 インシデントの長時間化
よくある失敗例2で、たくさんのサービスや技術要素が関係する、というお話をしました。
多くの要素が絡むということは、運用担当者にもそれ相応の技術スキルが必要です。
障害や問い合わせが発生した際、それぞれの異なる窓口に対して状況を正確に伝え、目的の回答を得る。
これはなかなか簡単なことではありません。

じゃあなんのためのサポートなんだという声が聞こえてきそうですが、残念ながら、実態はこのようなことは少なくありません。
単なるオペレータでは窓口のたらいまわしが発生し、インシデントの長時間化という結果が待っています。
よくあるSAPシステムの例を取ると、こんなかんじです。
 SAP・・・SAP OSS
 ジョブ/監視・・・日立
 OS・・・Microsoft
 サーバ・・・HPサーバ窓口
 ストレージ・・・HPストレージ窓口
 バックアップ・・・HPソフトウェア窓口

この例では、サーバ、ストレージ、バックアップをHPから購入していますが、
サポート契約が別々という例です。
これらのサポートレベルはもちろんまちまちです。
受付時間、初動までの時間、土日の対応、保守費、契約体系、バージョンアップ権、障害と通常問い合わせ、代理店とメーカー・・・
サポートと一言で言っても、何から何まで定義がバラバラです。

ですので、あの窓口はあのレベルだからこういう話し方、こっちの窓口は・・・
と窓口毎に担当者のスキルレベルも異なるので、障害の短期解消を目指すために担当が回答しやすくなるよう、
動きやすく情報を提供する、という問い合わせ方をしないと、どうしても長期化しがちなのです。

○ではどうしたらよいか?
よくある失敗事例として3つあげました。
これらは実際に弊社自身が過去陥った失敗です。
ではどんな体制を組めばよいのか、どんな運用ベンダに依頼をすればいいのでしょうか。

思いのほか今回の「運用で失敗しないために 後半」が長くなってしまいました・・・
次回「運用で失敗しないために 後半2」として、運用体制の組み方について書きます。

カテゴリー: お知らせ

運用で失敗しないために 前半

最近、運用のご相談をいただくケースが増えています。
いや、増えているというより、構築のお話が減っているのですね。
数年前から「既にSAPは飽和状態」などという話が出ていましたが、
いよいよかな、という気がします。
これまで、バージョンアップやHANAの一過性のトレンドはありましたが、
市場としては運用/保守の比率が高くなっているのでしょう。

運用というと、弊社はとても思い入れが強い分野です。
どんなに優れた機能を搭載したシステムであっても、
使っていただかないと作った意味が薄れてしまいます。

運用と一言で言っても、システム規模の大小とユーザさんの文化によって、
その形は色々です。
弊社では、運用に至るまでに運用設計の自体を「運用方針作成」として定義します。
その後、運用設計として「SLA」「運用業務一覧」「運用業務フロー」に落とし込ます。
運用設計と並行して、運用/保守ベンダさんの選定や引き継ぎのお手伝いをしたり・・・
そのユーザさんの文化に合わせて参画範囲や深さは色々です。

そんな色々な運用、最後はITILや運用ベンダさんのなんらかのフレームワークにあわせて、
チケット制やベースライン制などの課金体系を決めたらいよいよ準備完了。
この金額と体制、毎回試行錯誤をするものの、「これが正解!」といったものはありません。
チケット制が合うユーザさんもいれば、ベースライン制のほうが予算管理がしやすかったり、
シェアドサービスで充分なケースもあれば、フル常駐型を希望するユーザさんもいたりします。

そうはいっても、なるべくユーザさんが満足する形に近づけるためにも、
運用設計のアプローチは必須です。
システムの大小や文化を問わずです。

次回、失敗例や実際に運用の現場で起こる事例をご紹介します。

カテゴリー: お知らせ

本番機SPS適用

とあるユーザさんの本番機SPS適用(2年分)とカーネル最新化作業を実施しました。
今回の作業、とにかくサーバ台数が多いのが特徴です。

ECC20台、EP10台、XI2台、合計32台・・・・
1ぺレーションにつき1スクリーンショットを取得、レビュー者が常時張り付き。
作業者は私含め2名。いやー、壮絶な作業でした。
とくに、各DIサーバでのSAPOSCOLからHOSTAGENTへの置き換え作業が地味に激しい作業でした。
NWDIでのコンポーネント配布もありました。私の担当ではありませんでしたが、
なかなか見る機会が無い作業でした。

ともあれ、土日月の3日間で予定どおり作業完了。
本番機作業は緊張しますね。

カテゴリー: お知らせ

Software Provisioning Manager 1.0の不思議

最近のSAP製品のインストールをして知ったのですが、
SAPINSTの起動がちょっと変わりましたね。

Software Provisioning Manager 1.0 というものです。

これまではSAPINSTといえばインストールキットに同梱された
「InstallationMaster DVD」を使用し、中のSAPINSTを起動していました。

最新のERPをMarketplacesから「InstallationMaster DVD」をDLしたところ、
解答するとなんと中身が空っぽ!
「今後はSoftware Provisioning Managerを使ってね」と1行書かれたテキストが入っているだけです。

さっそくこの「Software Provisioning Manager 1.0」をDLしたところ、
無事インストールが出来ました。
中にSAPINSTが入っていますので、メディアが変わっただけで手順は一緒ですね。

何が変わったかというと、いろんな製品の「InstallationMaster DVD」が統合されたので、
製品の品質が上がる?らしいです。
これまでのようにSAPINST自体のバグでインストール作業が出だしから遅延することもなくなる?

ちなみに、SolutionManager7.1、NetWeaver7.3、SAPERP6.0 EHP6 とインストールを実施してみましたが、
「Software Provisioning Manager 1.0」自体にも細かくバージョンがあります。
「Software Provisioning Manager 1.0 SP3 for NW 7.0x」 と、
「 Software Provisioning Manager1.0 SP3 for NW higher than 7.0x 」
バージョン管理が一層複雑になってないか???
Software Provisioning Manager

・ダウンロード
http://service.sap.com/sltoolset -> Software Logistics Toolset 1.0 -> Software Provisioning Manager

・リリースノート
ノート 1680045 – Release Note for Software Provisioning Manager 1.0

カテゴリー: お知らせ

仮想化と検証環境

そのむかし、R/3(R/2)と名乗っていたパッケージは、
3.0 → 3.1 → 4.0 → 4.6 → Enterprise → ECC → SAPERP・・・・と名前を変え、
最近はEHPxというあたかもパッチレベルのようなライト間隔なバージョンも出て来ました。

そして、Netweaver2004と呼んでいたものは7.0、7.1、7.3が混在することに。

バージョンがなんだろうが基幹システムに求められる業務要件はさほど変わらないものですが、
基盤に求められる非機能要件は日々進化を続けています。
その進化をうけてのバージョンアップということが言えるのでしょうが、
いやはや、扱う側はたまったものではありません。

こんな複雑なSAPベーシス分野に加え、ミドルウェアやOS、DB、H/Wとなると目が回る複雑さです。

そんな基盤泣かせな時代の救世主(?)が仮想化技術です。

弊社もVMwareとHyper-Vには力を入れてきていますが、H/Wから開放されるのがこんなに気持ちの良いものかと驚きます。
すごい技術ですね。

ただし、運用する側にとっては管理する対象のレイヤ(仮想レイヤ)が増えるため、運用難易度は上がります。
これまでのリソース監視の考え方を進化させないといけないですし、
追加ホストが気軽に出来るためにどんどんゲストOSは増えていきます。
仮想化エンジニアのケアを忘れずにお願いします。

話を戻して、最近のSAP案件はバージョンアップやシステムコピー、マイグレーションといった、
保守案件が増えています。
お声がけいただいて訪問したユーザさんのSAPバージョン、見事なまでに毎回違います・・・
昨年は ECC5.0からのバージョンアップを担当させていただきました。
ECC5.0・・・けっこうマイナーなバージョンです、存在をすっかり忘れていました。

ベーシスに係る方はご存知だと思いますが、SAPのインストールメディアというものは、
出荷時のセットを保持していないとインストール作業がうまく進みません。
そして出荷時のセットは数ヶ月に1回マイナーバージョンが変わりますので、
ぱっと見同じバージョンであっても、インストーラのメニューが違ってたりします。

そんな出荷メディア毎に手順が変わるSAP、さすがに何らかの検証をしないとユーザさん先での作業はリスクです。
そこで弊社ではVMwareによる事前リハーサルを実施するようにしています。
当時のメディアを使ってシステムコピーやバージョンアップの計画を立てるために、
気軽に環境構築ができるVMwareは重宝します。

今日もVMwareを使ってバージョンアップの手順確認と、VMwareソリューションの調査です。
しかし、VMware自体もバージョンが小刻みに上がっていてこれもまた基盤泣かせではありますが・・・

カテゴリー: お知らせ