ハードウェア障害
こんばんは、カズヤンです。
今日は、朝から強烈な体験したので書きます。
月曜は日曜からの憂鬱な気持ちをなんとかふっとばさないとやってられないので、
電車の中で綿密に計画を立てて、出社しました。
8:30 〜 〇〇案件の手順書修正する
8:45 〜 IT資産の棚卸計画作る
的な感じでシミュレーションして、自分のフロアのドアを開けたら、
いつも10:00に出社する私の上司がなんと8:30に会社にいるのですwww
なんか超絶、悪い予感しかしないなあ...
と思って、
私：(上司)さん、おはようございます....
と言ったら、
上司：昨日、〇〇案件のサーバ落ちたのよ...
私：へっ？？、まじすか？？..
上司：おん、んで昨日の夜中までやりとりしててあんま寝てねえよ..
私：おおっ、お疲れ様です...
日曜夕方に優雅にウォーキングしていた自分が恥ずかしい....WWW
本番機サーバは、主系(DBサーバ)・従系(APサーバ)のクラスタ構成をとっているため、うまい具合に従系(APサーバ)にフェールオーバし、業務影響はなかった模様...
どうやら、H/Wの一部が壊れていたとかいないとか、それをシステムが検知して止まったらしい。うちの責任範囲外ということで処理は終わり。H/Wベンダーもこれが休日で助かったなとなぜか自分も安心..
ただ、OSのプロセスが落ちて死活監視(Ping監視)引っかかることなんてなかなか見れるものじゃないので、個人の興味としてとてもありがたい経験だと思います。
あとは、こんなトラブルが起きた時も先輩SEが迅速に対応する感じがなかなかかっこよかったのでモチベ更に上がっています。
今のチームに入って5ヶ月が過ぎたわけですが、たくさんの障害に遭遇してきて今までで一番大物の障害に遭遇できたので、月曜から特別な気分です...
本障害の後処理に追われて自身の業務が全然進まなかったのですが、色々学べた月曜でした...
イベント当選!!
こんばんは、カズヤんです。
先週寄稿したブログにて、SAPイベントが今週開催されることを触れました。
さっきPC開いてページ開いたらイベント当選通知が届いてました!! まじきたっ!!
当初は、応募者が50名のイベントでしたが(私が応募した段階で49名/50名ww)、なんと数回の募集枠拡張で130名までのイベントになっておりましたwww
ちなみに、イベントはデータベース勉強会という体制をとっており、アクセンチュア、Amazon Web Services、SAPの3社共催のイベントです。
「守・破・離」と3本だてになっているため、極力全部出て全貌を掴みたいところ...
最初の「守」に参加できることにとりあえず安心しましたww
今後の日程としては、下記のテーマで開催されるそうです。
Vol.1（守）：12/21(木) 「DB進化論」
Vol.2（破）：来年2月頃 「OLTPとOLAPを一つのDBで実現（仮）」
Vol.3（離）：来年3月頃 「インメモリデータベースの今後。カラム単位管理のデファクト化と新領域への適用可能性（仮）」
とりあえず、初回はDBの変遷の歴史をたどっていく感じから始まるのでしょう。そのあとは、HANA DBに関するところに触れていく感じかな(?)。
私も今年からDB管理者として業務を行なっていますが、今後2025年以降SAPシステムは、Hana対応を迫られるので、インメモリの仕組みに関しては理解して置かないとやばいはず...
参加者一覧を見ると、20代後半〜40代半ば的なレンジですね。
おそらく、皆さんかなりのDBもしくはSAPプロフェッショナルだと思うので新人の私が相手してもらえるか全くわからないところではありますが、いろんな情報交換できたら嬉しいですね。
学生の時は、ソーシャルセクターのイベントのお手伝いとかしていたので、こういうイベントって結構あったのですが、自分が本当にプロとしてやっている分野のMeetupイベントってかなりワクワクします!!
よく社内でも先輩と会話しますが、私の会社の運用体制と他社の運用体制ってどれくらい違うのかとかって結構気になっています。会社によっては技術者が多く、マネジメントが弱い会社では、そもそも作業手順書の配備がしっかりなっていないなんてざらみたいな話ありますからねww
ということで、3名くらい同年代のSAP Basisコンサルタントの人と知り合いたいですね。シニアの人になると会社に何十人もいるのでぶっちゃけその辺は不要ですねwww
あとは、イベントが木曜なのでそれまでOracleDBについて沢山学習してキャッチアップでせねばまずいです。
これに関しては、木曜結果報告ということで記事を寄稿します!!
では、またよろしくお願いします!!
SEとして海外で働きたい（③ドイツ移住に関して）
こんばんは、カズヤんです。
忘年会続きで、3日ブログを更新できませんでしたが、また今日から書いていきます。
結構、ブログを3日書かないだけで自身をリフレクションの時間があってある意味充実していました。今日は、そんなリフレクションの中から生まれたアイデアなのですが、ドイツ移住ってできるのかなと思って書いてみようと思います。
目次：
１、ドイツの魅力
２、日本との違い
３、ビザに関して
４、終わりに
１、ドイツの魅力
そもそもSAPってドイツの会社ですから、そのシステムが作られる本場に足を踏み入れたいというのは自然の願望だと思います。ちなみに本社はドイツのヴァルドルフという都市に位置しています。多くの日本人が駐在するデュッセルドルフなら聞いたことありますが、私もここは知らなかったです。
SAP Office Locations | Headquarters, Labs, and Training Centers
起源は、ドイツIBM出身のエンジニア4名がIBMで培ったシステム構築の知識をERP開発に注ぎ、そこで誕生したのがSAPというERPパッケージだそうです。
ドイツは、日本に次いで世界第４位の経済大国であり、自動車などの製造業がとても盛んな国として有名です。ギリシャのデフォルト危機の際にもEU内で最も発言権を持っていたドイツの動向が注目されていたことからも、ドイツのヨーロッパにおけるプレゼンスは高いでしょう。
さらに、敗戦国として日本と似た歴史を持っていることから、いかに今までの地位を築いてきたのか、学ぶべき点があると思います。
もう１点面白いのが、首都であるベルリンは世界のスタートアップシーンでも活躍しています、下記世界スタートアップランキングにおいてもベルリンは順位を上げてきています。どのランキングサイトがデファクトスタンダードなのかわかりませんが、2017年11月度の下記ランキングによると、ベルリンは全体の2位と記載されており、まさかのサンフランシスコよりも上に来てるのには驚きましたww ↓↓
私は、Basisコンサルタントという立場ですが、DBエンジニアとしても携われる機会がないわけでもないと思ってるので、新しいものがどんどん生まれるクラスター内で仕事がしていたいです。やっぱ、自分と同じITのフィールドで活躍されている多くのエンジニアの方と交流したい気持ちがあります。なお、大変残念ですが、このランキングトップに日本の都市名はありません…
２、日本との違い
■仕事に対する意識の違い
ドイツの魅力をあげるとするならば(日本以外の先進国はそうなのかも知れませんが)、ドイツでは日本ほど仕事中心主義の、いわばワーカホリックは存在しません。彼らは終日たくさん働き、土日は徹底的に休み、ビールを飲むのです。
あとは、集団を重視する日本の組織と異なり、ドイツでは個を重視するなど、組織に対する帰属意識が低いのも特徴だそうです。私のドイツの友人は、
会社は彼の夢を実現するためのツールに過ぎない
とか普通に言っています。私もフローランスやりたい人なのでその風潮には同意です。
■わりと英語で業務ができること
とても意外ですが、ドイツの求人は割と英語話者であれば問題なく受け入れてもらえるという側面があります。特に、ITに関しては、技術発祥がアメリカのものはソースが英語でリリースされるため英語が話せないと逆にまずいということだそうです。
なお。SAPに関しても英語話者であれば問題ない旨、SAP社の求人サイトに掲載があります。
SAP Basis-Jobs - Dezember 2017 | Indeed.com
ただ、ドイツで生活する以上ドイツ語を日常会話に一切問題のないレベルまで対応できる語学力は必要かと思います。
３、ビザに関して
■ワーホリビザから就労ビザ
私も最近ドイツに住んでいる友人から聞いた話ですが、ドイツでは31歳以下まではワーホリビザにより２年間国内で就労できるそうです。オーストラリアなどでは、国が定めた農業などの職業につく必要がありますが、ドイツでは関係なさそうです。そのため、就労ビザを取得するまでの期間の2年間をワーホリビザ取得して対応できれば今後のドイツでの生活の可能性を考えながら業務に当たれると思います。
４、終わりに
私は、今の会社に入社する前からリタイアしたらスイスのアルプスの麓で素敵なじいちゃんになるという謎の欲望がありました(「夢」ほど難しくなく実現可能なものであるためあえて、「欲望」と言っています)。ちなみに、スイスではドイツ語、フランス語、イタリア語が話されているため、ドイツ語の学習をすでに始めています。
ドイツ語は一見するとむずかしく感じますが、英語と文法が類似していたり、単語も似ているため、英語が問題なく話せる場合はそこまで苦労せず習得が可能だと認識しています。
丸3日ブログを更新していなかったにもかかわらず、50〜100PV/日で推移しており、ニッチブログとしてはかなり好調で、いつも本ブログを閲覧してくださる皆様には大変感謝しております。
他にも気になっている国がいくつかあるので、私が直接訪れた訳ではなく２次情報で恐縮ですが日本にいる間にこの妄想記事をどんどん書いていきます。
大変恐縮では、ありますが今後ともどうぞよろしくお願いいたします。
エンジニア？テクノロジーコンサルタント？
こんばんは、カズやんです。
今日は、エンジニアというよりテクノロジーコンサルタントでよくね？っという点について綴っていきます。
というのも、最近自己紹介するときに、
エンジニアやっていますカズやんです！！
っていうと、プログラミングできるんですか？とか言われるますが、実際はコーディングそんなできるわけでもないので困ります。あとは、世間一般的にエンジニアは地味で陰険な人が多いので、少しネガティブなイメージを持たれてしまいます。
そこで、少し前からですが、
テクノロジーコンサルタントのカズやんです！！
というようにしています。
この方が、なんか活き活きしていてポジティブな印象を相手に与えられるのと、なんと言ってもかっこいいこれに尽きます(ただし、単にコンサルとは言いませんw)
この理由についてちょっと語らせてください。
ひとえにコンサルと言っても最近では、戦略コンサル、 ITコンサル、財務コンサル、人事コンサル、オペレーションコンサルとか色々あってわけわからんですよねww
おそらくコンサルと言ったら戦略コンサルのことをさすでしょうし、皆さんも戦略コンサルを連想するでしょう。
ただ、そもそもコンサルってなんでしょうかね？？
人・企業が抱える問題をソリューションで解決する人のことをコンサルティング
というわけで、エンジニアもコーダーでない限りは、お客さんの課題に対してロジックを駆使したり、技術を駆使して解決するわけです。そういう意味では、コンサルやろと思いました。
あとは、SAP Basisって日本よりも海外に技術者がいるのですが、彼らのプロフィールってそのほとんどがSAP Basis Consultantになっています。
実は、日本ではSIerなどで業務を行う技術者のことをエンジニアと呼びますが、海外ではテクノロジーコンサルタントと呼ぶ風習が少なからずあるそうです。よくLinkedinで海外の技術者と連絡をとるのですが、あるインドの技術者でBasisは10年経験ある32歳の人ですが、聞くところによると彼の周りのSAP Basis技術者はコンサルタントと名乗っているそうです。これは、上記の問題解決の理念によるものだそうです。
ちなみに、お客様に提出するサービス提案書でも「SAP Basisコンサルタント」と明記されます。
今回は、SAP Basisの話を例に出しましたが、エンジニアの方は今後はテクノロジーコンサルタントと名乗りましょう！！
その方が、依頼する側のお客さんも単なる友人でも印象変わります。
私も、本ブログでも自己紹介する時も、
テクノロジーコンサルタント
と言いまくります。
※今はブログを少しでも浸透させたいので、タイトルはまだ「テクノロジーコンサルタント」にはしません。
すごい勝手な話でしたね、では今日は失礼します！！
SAPにおける表領域(Table Space)
こんばんは、カズヤんです。
今日は、Oracleを学んでいることから、現在SAP Basisで私が管理することもある表領域に関して書いてみようと思います。
まずは、表領域についてですが、表領域には表(テーブル)データが格納されています。表データは、システム内で用いられるデータがSQLによって整列された形で格納されたデータのことです。
例えば、給与計算システムがあったら、社員番号と給与は必ず記載があって、あとは年齢、性別、勤務年数、役職、名前などが一つの表になって記載されているはずです。
SAPはERPなので、これら給与に関するものだけでなく、あらゆる社内データをデータベースにて管理しアプリケーションで呼び出す必要があるため、大量の表データが存在します。その表データは表領域に格納されています。
特に、メジャーな表領域が
・PSAP<スキーマID>
・PSAP<スキーマID><リリース>
・PSAP<スキーマID>USER
これら3つの表領域がメジャーっぽいです。
まず、PSAP<スキーマID>に関してですが、全SAPオブジェクト対象のテーブルが格納されます。なお、SAPシステムのテーブルの中でもこのテーブルが一番容量が大きい気がします。
補足ですが、さすがに表の種類はアプリ担当が知るべきところなのでカバー外ですが、よく出てくるのが、BSISテーブルです。これは、SAP FI関連の会計テーブルで、総勘定元帳：未決済明細データを格納するテーブルだそうです。これめっちゃ出ますし、容量も大きいですww
次の、PSAP<スキーマID><リリース>に関してですが、これはリリース依存のテーブルが格納されます。例えば、SAP Basis 700とかのリリースなら、PSAPSR3700みたいな感じの名前でよく出ます。リリース依存のため、量は少し小さくはなりますが、大切なところです(口では、そう言いますが、実際どんなデータが入っているか調べていませんwwリリース依存だから、そのバージョンのみ使用可能なAddonや修正パッチのことだと思います)。
最後に、PSAP<スキーマID>USERに関してですが、これは全カスタマオブジェクト対象の表領域です。カスタマオブジェクトとは、おそらくですが、ユーザーがカスタマインジングしたオブジェクトということだと思います。これ、調べてもあんま出てこないので濁しておきます。ただ、これも、ユーザ固有のものという意味では大切な表領域なので絶対知っておいた方がいいです。
今日は、SAPシステムにおけるメジャーな表領域について共有しました。SAP Basisコンサルタントの重要な業務であるDB管理の中でも表領域管理はとても重要です。中でも「表領域拡張作業」は覚える必要があると思います。これは、特別なBRツールにて行う作業で、SAPコンサルとかでもでるらしいです。
正規のOracle Masterとは逸れましたが今日はここまでで失礼します。
では、また!!
SAPコミュニティについて
こんばんは、カズやんです。
早いもので、もう月曜日で仕事が始まりますね。自分は土曜はずっと引きこもりでOracleの勉強していましたが、今日は少し都内を散策していました。
そんなこんなで、今回はSAPユーザーのコミュニティを以前から探していて、
JSUGというなかなか大きなSAPコミュニティがあることを知りました。
Japan SAP User GroupというSAPのユーザ企業で構成されている団体です。
SAPの勉強会的なこともやっていてかなり啓発的な団体で、めっちゃ羨ましいなあと思って見ていたのですが、私の所属している会社も普通に協賛の一覧にありました。
ってことはと思って、１つ先輩の社員に聞いて見たら、普通に勉強会に出席しているらしいです。私の部署で知らないのは私だけだったらしい。普通に共有してほしいっすねww
ちなむと、JSUGは結構公式な団体ですが、
SAPのリーディングカンパニーであるAccentureやサポートをしているSAP社、AWS社による共同イベントも近日催されるらしく、私も参加申し込みしました。
どうやら、「守・破・離」と3本だてになっており、第1回目はデータベースがテーマとなっており、ちょうど私が現在猛烈に詰めているOracleやHANADBの話が聞けるそうです。
参加者もDB専門、クラウド専門、プリセールスなど幅広い経験をお持ちのかたがいらっしゃるそうで、とても楽しみですが、これ今見たらまさかの抽選方式でしたww
当たったらていうか、当たってもらわないと困るwww
こんな感じで紹介しましたが、Facebookでもコミュニティがあり、そちらは10000人ほどのグローバルコミュニティでインド人がたくさんいるのでシステムについて色々質問できると思います。インド人はとても気さくで私もフロントエンドの質問をしまくりましたが、親切に返信してくれるので感激しました。
とりあえず、JSUGに行かせてもらいたいので、会社に法人会員枠にこと聞いて見ますw
もし、JSUG会員の方いらっしゃたらめっちゃ色々教えてもらいたい。
それでは、今日はここまでで失礼します。
明日も引き続き頑張ります!!!
パッチ適用に関して思うこと
こんばんは、かずやんです。
今日は、SAPのパッチ適用に関して書いていきます。
以前から、SAP GUI 750に関しての業務ばかりに辟易していることに関して書いていたと思いますが、最近SAP社と毎日問い合わせをしており、すごく疑問に思うことがあります。
フロントエンドでの問題がある時に、その事象って大半はSAP Noteリリースされていて、SAPも把握しているようなエラーであることが多いです。そして、修正パッチに関してもNoteリリースされているエラーを修正するパッチであることは明記されているわけです。なので、ユーザ側にパッチを当ててもらうわけですが、改善しない事象も存在します。
改善しない理由として、SAPとしては、GUIやBExなどのフロントエンド関連のファイルが端末に残っている可能性があると言うわけです。ただ、実際には古いファイルが残っていないというケースも十分存在します。
つまり、SAPシステムにプログラムエラーが依然として存在している状況というわけですね。
ここで、SAPとしては、SAP GUIとBExのアンインストールを行い、再度インストールをしたら事象が改善されるというわけです。
本番稼働環境の中で、そんなことやってられなくね？
ってのが正直なところで、そもそものパッチの意味って、プログラムファイルを実行してパッチを適用するだけでエラーなり事象の改善が期待されるもののはずですよね？
毎度、エラー出たら再インストールとかやってられねえよLLLL
ここ最近のSAPの対応の適当さには、腹たちます。
パッチ適用ってインストールするだけで直るからリリースしてるんやろ、あほか！
てのが僕の意見です。
個人的にSAPに携わっている社外の知り合いもいて、まあ新技術に対しては対応がおざなりになる旨語っていますね。
SAPの悪口みたいで申し訳ないですが、実際のところSAPには純粋なカスタマーフィードバックとして、受け取って欲しいと強く思います。
今SAP社では、エキスパートチャット機能など便利な新機能が追加されていますが、これらは現在のところ英語対応のみとなっていて日本での普及は難しいのが現状かと思います。下記のリンクを参照ください↓↓
Basisを担当しているということは、少なからずABAPerではないので、修正プログラムに関してもSAPに任せるしかないですよね。
SAP GUI750が2019年までのサポートになっていますが、GUI760リリースされたらまた面倒くさい問い合わせ増えると思うと萎えますね。
Oracle勉強しといて助かった件
こんばんは、かずやんです。
今日は、担当案件にて内部月次ミーティングがあったのですが、ミーティングをインフラチーム1名、Basisチーム2名、アプリチーム2名で実施するわけです。
基本的には、我々Basisが招集をかけ、Basisの前月の作業内容をアプリ側に報告するわけですが、現在月次報告の3割を私が担当し、7割をPMの先輩が担当するという形で行なっています。
Basisの話が終わって、無事に内部報告も終わりかと思った矢先に、
空気のよめないインフラ担当のエンジニアの人がごちゃごちゃわけわからんことを言い並べるんです。
まあ結論言うと、そのお客様のシステムの本番機を昨年度からDB2のフルバックアップしかしていないため、年末年始にSAPシステムの全部をシステムバックアップを取りたいということでした。
もし、バックアップを取らないとなると、SAPシステムがこけた時に、2016年2月までのデータは復旧できるけど、2016年2月〜現在までのデータの復旧はできないと言うこと。
ただ、バックアップを取れば、作業自体はクソめんどいけどシステムの復旧は楽になると言うことです。
そのため、2016年2月から現在までのシステムの変更作業の履歴を調べて、バックアップを取らない場合のリスクを確認しました。
まあ、この会話の中で、「バックアップ」、「リストア」、「リカバリ」などの単語を聞いて、ちょっと興奮しましたね。
「フルバックアップ」とか「データバックアップ」とかも出てきて、勉強しておいたおかげで速攻議事録が書けましたね。
PMと話す時もすごいデータベースのバックアップに関して知っている感を出して話すのが痛快でしたが...ww
案件のデータベースはDB2ですが、Oracleにも共通のバックアップ概念のため汎用性は高いです。
とうわけで、週末も引き続き学習のモチベーションが保てそうです。
今は、表領域について学習しているので、この辺の情報も共有できたらいいなと思ってます。
では、今日はここで失礼します！！
