AIによるSAP運用の自動化
こんにちは、カズヤんです。
今日は、AIを用いたSAP運用の自動化について書きます。
SAPに関しては、現在多くの技術者がいますが、システムのライフサイクル的には必ず運用フェイズがあるはず。
運用に関しては、ある程度規則性のある作業が多く、その作業をわざわざ上流の技術者が担当する必要はなく、ほとんどを外部委託(アウトソーシング)することが多いです。以前の記事に記載しましたが、運用に関しては、社外の専門業者もしくは、社内のオフショア部隊に定型作業を委託するのが一般的になっています。
最近、面白い記事を見つけたのですが、インドのタタグループのIT部門であるTCS(Tata Consultancy Services)が運用に特化したAIであるIgnio for SAPを市場に投入することが発表され、私も情報を見たのですが、SAPシステムの運用で行なっている定型作業のほとんどはIgnioが自動でやってくれるそうです。IBMのWatsonとの違いはよくわかりませんが、SAPシステム専用の運用ツールって多分世界初なんじゃないかと思います。
下記がプレスリリース(2017年9月のニュースで恐縮ですが) ↓↓
TCS Resources: : 日本TCS、AIを搭載したIT運用ソリューション「ignio」を展開
TCSの社内ベンチャーのdigitateという会社がIgnioのソリューションを提供しているようです↓↓
SAPシステムの運用に関しては、結構いろんなことをやりますが、
SAPシステムの運用業務では下記タスクの自動化を行えるようです。
・ユーザ管理
・ジョブ管理
・移送管理
・Note管理
・IDoc(システム連携の話、筆者はあまりわからない..すみません..)
・ABAPダンプ管理
・ダイアログレスポンス管理
一部まだわからないものもありますが、
今ってどこのSAPシステム運用会社でも、上の管理業務には手順書を用いて対応していると思います。
多分ユーザ管理とかに関しては、依頼をもらって、作業して作業報告までの時間で1時間くらいかかるはずですが、Ignio使うと5分くらいで終わるんじゃないですかねwww
多分、意思決定の部分だけエンジニアが担当する的な感じになるのかな..?
これらが自動化すると定型作業を実施しているエンジニアの需要は一発で無くなります。
まだ、導入がそこまで浸透していませんが、これがどんどん浸透した時に、
運用エンジニアの超過供給になり、現在この業務に従事している人の仕事はなくなると思います。
個人的には、3年は様子を見たいですが、SAP Basisに従事している方はなる早で構築業務に行くか、BPR案件で新しい価値の創出を試みることをお勧めします。
フェイルオーバ時のGUI接続先設定
こんばんは、カズヤンです。
今日は、クラスタ構成と負荷分散について書きたいと思います。
以前、ハードウェア障害でサーバがフェールオーバしたことを書きましたね。
インシデントが発生した際に、サーバへの接続確認をteratermとSAP GUIにて行うこと
がありますが、どうやら仮想ホストIPアドレスをSAP GUIの接続先設定として登録して居なかったため、インシデントが起きてから、仮想ホストIPアドレスを登録することになったのです。前回のインシデントに対しての問題管理としてGUI設定の是正をしている感じです。
現状は、こんな感じでサーバ構成されており、
SAP GUIでは、主系サーバと従系サーバの物理IPアドレスのみが振られているため、
主系サーバが従系サーバにフェールオーバした際に、サーバ毎に接続確認するのが面倒臭い状況が起こり得ます。どう言うことか以下で説明します。
サーバ構成は下記のようになっています。
なお、ここでのクラスタ構成は、負荷分散クラスタではなく、高可用性(HA)クラスタを想定しています。そのため、SAP GUIにて、仮想ホストIPにログオンした際には、必ず主系サーバにログオンする設定とします。
もし、これが負荷分散クラスタ構成となっていたら、仮想ホストIPにログオンした段階でトランザクションの処理に利用されるリソースが余っているホストにログオンすることになります。繰り返しですが、今回想定するのは、高可用性(HA)クラスタです。
主系サーバおよび従系サーバが正常稼働している際には、ステータスは以下のようになります。
Ping:
仮想ホストIP(172.35.30.11) 疎通可
主系サーバ(172.35.30.12) 疎通可
従系サーバ(172.35.30.13) 疎通可
SAP GUI:
仮想ホストIP(172.35.30.11) ログオン可
主系サーバ(172.35.30.12) ログオン可
従系サーバ(172.35.30.13) ログオン可
なお、以下が主系サーバがなんらかのトリガーにより、従系サーバにフェールオーバした後のサーバ構成です。フェールオーバのトリガーに関しては、クラスタ構成ソフトを販売しているベンダーのHPにて確認ください。このあたりもある程度は設定ができるっぽいです。大抵はネットワーク障害やハードウェア障害がトリガーとなりますが...
主系サーバがフェールオーバすると、まず、クラスタ構成にて事前に設定していたパッケージが従系サーバに移動することになります。SAPの場合、主系サーバで稼働していたセントラルインスタンスが従系サーバ上で稼働することになり、従系サーバで稼働してたダイアログインスタンスが停止することになります。
サーバのステータスは以下のようになります。
Ping:
仮想ホストIP(172.35.30.11) 疎通可
主系サーバ(172.35.30.12) 疎通不可
従系サーバ(172.35.30.13) 疎通可
SAP GUI:
仮想ホストIP(172.35.30.11) ログオン可
主系サーバ(172.35.30.12) ログオン不可
従系サーバ(172.35.30.13) ログオン不可
となります。
主系サーバが落ちているのでもちろんPingもSAP GUIもアクセスはできないです。
クラスタ構成をとっているので、SAP GUI上では従系サーバにもアクセスできません。
ユーザ側では、本番機サーバにただアクセスができる環境であればどこにアクセスできても同じことなので、仮想ホストIPをGUIで設定しておけば、何も問題はありませんが、我々のようなシステム管理者はこのGUI設定を常にどのサーバにも迅速にログオンできる設定にしておく必要があります。
現状:
主系IPアドレス
従系IPアドレス
是正策(1):
主系IPアドレス
従系IPアドレス
仮想ホストIPアドレス
是正策(2):
仮想ホストIPアドレス
従系IPアドレス
と考えています。
ここで、大切な要素となるのが、どこでシステムの負荷分散をしているのか?と言う点です。
負荷分散をSAPシステムのユーザログイングループ設定をしている場合で、サーバ側で負荷分散クラスタを設定していない場合には、仮想IPにログオンした場合には、確実に主系サーバにログオンできる証左があるので、どちらの是正策でも問題ないと思っています。
ただし、
サーバのクラスタ構成で、負荷分散クラスタ設定を行なっている時には、仮想ホストIPにログオンした時に、主系サーバにログオンするのか、従系サーバにログオンするかはワークロード次第のため、不確実です。よってこの場合には、是正策(1)を検討して確実に入れるシステムを確定しておく必要があると考えています。
今話しているのは、システム管理者のGUI設定の話ですが、ユーザ側はただ本番機にログオンできればそれで問題ないので、システムの構成などどうでもよく、仮想IPで常にログオンしてもらうということで問題ないと思います。
ながながと語りましたが、結論として、
SAPシステムのサーバ構成でクラスタ構成をしている時には、必ずGUI設定を意識した方がいいです。
「どのシステムにいつでも入れるようにしておく」ために、GUIの接続先設定は全IPアドレスを追加することを強くおすすめします。
では、今日はここで失礼します!!
Note2449757(同じシステムの認証済RFCに置ける追加の認証チェック)を読み解く
こんばんは、カズヤんです。
最近、ブログを書く頻度を抑えてますが、書くときはしっかり書きます。
今日は、タイトルにもあるように12月度リリースのセキュリティNoteについて説明します。
ちなみにSAPはこういう技術情報を月次でリリースしているので、世界のSAPユーザはリリースと同時に確認し、自社システムにおいてどのような影響が出てしまうのかをその都度確認しています。私もお客さんに毎月重要Noteのリストを提出し、月次報告会にて説明するのがルールになっています。
今回は、Note2449757についてで、
同じシステムの認証済RFCに置ける追加の認証チェック
と言う題です。このままでは、意味がわからんすwww
現象をみると、
トランザクションSMT1で同じシステムへの明示的な認証済/認証関係は定義されていないにもかかわらず、認証済RFC接続を同じシステムの異なるクライアントまたは異なるユーザに確立することができます。(SAP Support Launchpadから引用)
と記載があります。
SAP Basisやって来て、頻繁にRFC接続と言う単語を聞きます。
RFCに関しては、下記を参照して欲しいですが、
RFC(Remote Fucntion Callの略)が、SAPシステム間の通信用インターフェースということを押さえておけば取り分け問題ないっす。
ちなみに、SAP GUI上では、Trcd:SMT1にて各システム(SID)において認証されているその他SAPシステムの詳細を確認および新規登録できるっぽいです。
で話それましたが、
Noteによると、
このTrcd:SMT1をわざわざ実行しなくても、同じシステム上なら自動で認証される設定になっている
らしいのです。
SAPは、クライアントというデータ構造をとっているので、各クライアント依存のデータがあったり、ユーザも使い分けられるので、同じシステム内でもクライアントとユーザ固有データが存在します。なので、デフォルトの設定で、同じシステム内でも、別クライアント、別ユーザを利用する際には、わざわざ認証がいらないということです。
これって、何が問題なのかと言いますと、
例えば、あるSAP開発機があり、クライアント500で、ユーザkazuyanという実行ユーザで特定ジョブを実行した際に、他のクライアント001とか005とかでもユーザkazuyanを実行ユーザとしてジョブが実行できてしまうため、セキュリティ的によろしくないということです。
これを回避するために、このNote2449757上に記載のあるカーネルパッチを適用することで、この認証のデフォルト設定を変更できるそうです。
ただ、カーネルパッチ当てたりしてシステムのグレードあげると、システムの別機能で不整合が起きてめっちゃ不具合起きるらしいので、カーネル関連の変更ってかなり避けたい作業らしいので、ほとんどの場合、無視した方がいいのかなと個人的に思います。
あと、今回の自動認証機能が問題になるのは、システムを「集中ユーザ管理」設定しているシステムにおいての話なので、そうじゃない場合はあまり気にしなくてもいいのかなと思います。集中ユーザ管理は、権限などをシステム内で一意にまとめてしまうため、今回の事例が問題になります。
まあ、著作権というか、重要な情報っぽいので、詳しくはSAP Support PortalにてSユーザログインし、確認いただけたらと思いますが、SAP経験者でもこのNote解読するの大変かと思いますので、理解の助けになれば幸いです。
私も今回のとこでRFCに関しては、見直しました。
今日は、ここまでにしますが、今回説明したNoteの解釈間違ってたりしたらぜひコメントください。
IPA試験の海外認証について
こんばんは、カズヤんです。
今日から、3連休ですね。
わたしは、今日も資格試驗に向けがり勉していますww
私自身が海外でエンジニアとして業務をしたいという願望があるので、
たまたま気になったのですが、IPAが認定している情報処理試驗って海外でも認証されていることってご存知でしたか!!?
あと、私のブログはSAP経験者の方々だけでなく、海外移住を目指しておられる方も多いため、東南アジアに興味ある方には有益な情報かと思います。
以前ブログにも書きましたが、日本人が海外でエンジニアをしたいってなったら、Engineering 関連の学位を持っていないとengineerとしての資質を評価していただけないようです。
下記の国々では、日本で取得した情報処理試験でエンジニアとしての能力を各国の指標で評価して貰えるようです。下記リンクをご覧下さい ↓↓
現状では、ASEAN中心の12カ国で認証を受けられるようです。
インド、シンガポールは優秀なエンジニアが多数在籍してしている方イメージが湧きますが、
韓国、中国とかはどうなのかww?
ベトナム、ミャンマーもインドに次ぐオフショア地域として勢いがあるので、ここでの認証も日本のSIerとしてはでかいですね(てか、そもそもSIerがオフショア候補先を東南アジアに寄せていったのを背景に日本政府が認証取りにいった感はありますが..)。
欧米の国々の認証が受けられないのはかなりいたいですね。
個人的には、先進国でSAPの仕事をしたいので、そこらの国の認証があってほしかったなあ..シンがポール認証は気になります..
と思った今日この頃です…
では、ここで失礼します..
saposcolについて
こんばんは、カズヤんです。
今日は、新年初出勤でしたが、年末年始も出ていたので、仕事モードであまり憂鬱な感じはしませんでした。なので、一発目から書いて行きます。
今回は、SAPの重要な機能の1つであるsaposcolについて説明します。
saposcolは名前の通りsapのリソース情報をOSから収集するための機能です。
私は、運用のチームに所属しているので月次報告書を作成する際に、CPU利用率やメモリ利用率を集計する必要があり、このsaposcolが収集したデータを閲覧します。
このsaposcolはSAPシステムとは別で存在し、os上で「ps -ef | grep sapos」みたいな感じで見るとsaposcol.exeみたいな名前のプロセスが存在するので、それがあったら、saposcolのプロセスが起動しているということです。
ちなみに、SAP GUI上にこのリソース情報を得るためには、Trcd:ST06を利用すると情報を確認できます。
saposcolの起動方法はosにより様々らしいですね。私のとこでは、HPUXとかWindows Serverとかなのであまり意識してなかったですが、おそらく運用やってるところなら、SAP停止・起動の手順書が存在すると思うのでそちらを確認して見ることをお勧めします。
てか、全部下記サイトに載ってるっぽいっすww
まあでも、SAPの仕組みを理解する上では重要なのでSAP Basis担当の方はぜひ覚えましょう。
今日は、ここで失礼します!!
明日は今週ラスト、頑張りましょう!!
国内SAPベンダー勢力図
こんばんは、カズやんです。
今日で、大晦日と元日のシステム変更作業終わりましたww
てか、大晦日の電車の空き具合がやばかったww
今日は、技術よりのことよりも、日本国内のSAPベンダーの競争力について見てみます。
今って、SAPバブルみたいなところがあってどこの会社も基幹システムとしてSAPを導入しているため、その過剰需要に応えるために多くの企業がSAP事業に参入しているのは言うまでもないことです。
SAPに関して、どこのベンダーが最も競争力が高いのかとか、指標がなかったのでイメージしづらかったのですが、どうやらガートナー社によって、国内のSAPベンダーランキングが発表されているようです。
2017年2月にリリースされたものなので、1年前の指標ですが参考になると思います。
下記をご覧ください ↓↓ 筆者の会社も入っていたのでテンション上がります ↑↑
引用)https://www.gartner.com/doc/reprints?id=1-3V872QJ&ct=170309&st=sb
この図はすごくわかりやすくて、水平軸に「Completeness of Vision(ビジョンの完全性)」、垂直軸に「Ability to Execute(実行力)」となっています。
お分かりかと思いますが、第1象限から第4象限まであり、以下のような位置付けが定義されています。なんかすごい経営学のフレームワークみたいですww
間違いなく、1番強いのは、Leadersの企業群です。一番悪いのは、Niche Playersの企業群です。残り2つ(Challengers、Visionaries)については、人によって、変わりますが、個人的には、リソース大きい方が有利な業界だと思うので、Challengersが強いのかなとか思ったりもします。
アビーム、アクセンチュアが第1象限に位置しているのは納得ですね。
JSUGの広告とかでもこの辺のベンダーはよくみますし、SAP Hanaの導入等も他のベンダーの先をいっているイメージがあります。アビーム以外は、規模の大きなベンダーなのでスケールメリットってとこだと思います。
第2象限は、SCSK、TCS、TISがありますね。TISはわかりませんが、商社系のSIerがいる傾向がありますね。SCSKに関しては、SAP以外にも、プロアクティブっていうERP製品を持っているので、SAPとの相性も良いような気もします。TCSは、三菱商事系の資本を背景に強い顧客基盤を持っています。GlobalのTCSがSAPの売上高半端ないと聞きます。
第3象限は、みてわかる通り、コンサルティング系ベンダーが顔を並べています。まあ、第1に技術者が少ないイメージがあります。コンサルティングのサービスはシステム戦略、要件定義やBPRがメインになるイメージがあります。Basis等のインフラ部分は弱い気がします。ただ、PwCに関しては、かなり熱心に採用活動をしているので、今後強そうな気がします。
第4象限は、謎にWiproが入ってますね。Wipro Japanはインド🇮🇳IT企業群SWITCHの一画で技術力は申し分ないと思います。ただ、SAPのランキングで国内でそこまで有名なイメージはなかったので以外です。個人的には、外資系の少数精鋭のベンダーは好きなので、Basisの技術者の方なんていたら会ってみたいですね。おそらくですが、TCS同様に、インドオフショアできるのがアドバンテージだと思うので、今後伸びるのでは?
このランキングを見て思うのが、ガートナーは海外の会社なので、グローバル企業を主に評価しているイメージがあります。実際、SAPを日本でやっていると、他にも有名で勢いのあるベンダーは実は結構あります。JSOLとか入っていないの意外でしたwwwあと、個人的に気になっているのがBeeXですね。クラウド移行に強みを持つベンダーで超勢いあります。私もめっちゃ移りたいwww
ただ、どうやらガートナーもこのことには触れていて、ランキングを出す時の定義を細かく載せているのでそこは確認してください。まあ、こういうランキングって完璧じゃないので、目安ぐらいな感じで捉える感じでいいと思います。
そんなこんなで自分のファームも載ってたのでテンション上がりましたが、今後もっと個人でも戦えるように力をつけていきたいと思います。
年末に書いたブログ記事の内容を今年度の抱負としてまた1年頑張っていこうと思います。
では、今日はここで失礼します
スキルと今後について
こんばんは、カズやんです。
今日は、SAP Basisコンサルタントとしての私のスキルについて触れると共に今後必要となるスキルを検討し、来年2018年の目標としていこうと思います。
第1に今年は運用チームの一員として2つのプロジェクトに所属して、多くを経験させてもらいました。
具体的には、
・移送適用作業
・SAP正常稼動確認
・ユーザ作成
・ DBパフォーマンスチューニング(インスタンスメモリ拡張)
・ジョブ設定
・障害対応(DB障害、ロックテーブルオーバフロー)
・SAP起動・停止スクリプト作成
・DB再編成(作業実施予定)
・月次報告書作成
・月次報告業務
などこれぐらいが挙げられます。
私が今後目指す場所としては、3年間でSAP Basisの全ての変更作業を独力で実施するということです。そのためには、バックエンドの経験が圧倒的に足りていないのが現状です。例としては、
・SP適用
・Note適用
・クライアントコピー
・表領域拡張作業
・Ehpアップグレード
などが挙げられます。私の現在アサインされているプロジェクトの状況を鑑みると、来年2018年度には経験させてもらえる気配はあるので、とてもワクワクしています。
これらの作業を実施することで、SAP Basisコンサルタントとして、どこの会社でも通用するスキルを持っていることを証明できます。来年度9月までにはできそうなので、配属後1年以内に達成できる気がします。
確認ですが、資格の棚卸しも大切で、現在は、
Oracle BronzeのSQL試験は終わっていて、DBAを学習中の状況です。加えて、基本情報技術者試験の学習も継続的に実施している段階です。
SAPコンサル試験は現在SAP ADM100を学習しているため、これを来年度4月までに完璧に理解するという目標で業務を行なっています。
現状はとても順調に成長できていると言えそうです。
来年度、社内の体制がどのように変わるかに関しては、まだわかりかねますが、今後も頑張って行きますので改めてよろしくお願いいたします。
では、今日はここで失礼させていただきます。
Active Directory をSAP GUIで利用
こんばんは、カズやんです。
今日は、アクティブディレクトリについて考えてみようと思います。
皆さん、マイクロソフト社のアクティブディレクトリって使ったことがありますか?
アクティブディレクトリは、シングルサインオンを実現するために用いられた技術です。
シングルサインオンとは、アクティブディレクトリ内のクライアントであれば、一度認証を行うことで同ネットワーク内の認証をする必要がないという機能です。
さらに、このシングルサインオンの機能とは別に、アクティブディレクトリ機能を利用することで同時に、同ネットワーク内のクライアント端末の設定をドメインコントローラにて一括で変えることができます。
※ドメインコントローラはアクティブディレクトリの対象となるネットワークを管理する端末のことです。全てのクライアント端末はドメインコントローラの設定を反映します。
例として、下記のリンクを参照ください。
このURLによると、アクティブディレクトリの管理者テンプレートを利用する事で特定のアプリケーションの機能をドメインコントローラにて一括設定が可能になります。
言っていることが難しいと思うので、繰り返すと、例えば、Google内のプロキシ設定を管理しているネットワーク内のすべてのクライアントにて反映させたい場合には、ドメインコントローラにて、Google chromeの管理者テンプレートを導入して、プロキシ設定を更新することで、同じネットワーク内のクライアントにもchromeの変更内容を反映させることが出来ます。
今回、SAPに確認したところ、SAPでは上記URLのGoogleの管理者テンプレートを用意していないそうで、SAP GUIのOptionの設定情報を変更することはできないようです。
ただし、SAP Note 608781を確認すると、SAPにおけるActive Directoryのサポートはあるようですが、SAP GUI750でサポートしているかは現状ではわかりません。Noteが古すぎるからです。
現在、SAP GUI750用のActive Directoryのサポートに関するNote608781の最新版をSAP社が、作成しているようでとりあえず待ちましょう(おそらく、管理者テンプレートは無いはずですが...)
では、今日はここで失礼します。