IBM 現場SEのITな日々

IBM現場SEが日々駆使している技術、現場SEの経験・知見を綴るブログです

（守田）SEとしての情報収集は何を利用していますか？

こんにちは。


私からはSEとしての情報収集について書こうかと思います。
職種柄、情シスのお客様と接する機会が多く雑談もしたりしますが、時々ふと質問されることがあります。一応大抵は答えることはできるのですが、恥ずかしながら返事に困ることもあります。そのような経験から、SEそれぞれの技術分野の情報源はさておき、個人的な趣味や偏見もあるかと思いますが、情シスのお客様目線で押さえておくべきと思われる新聞雑誌はこれらかなと。


新聞
 言うまでもないですが、お客様目線でいくとやはり日経新聞かと思います。そんなの常識といわれればそれまでなのですが。。。以前は新聞なら日経となんとなく思っていた程度でしたが、実際に日経新聞にセキュリティ関連の記事が掲載されると、必ずと言っていいほど問い合わせがあることがありました。もちろんセキュリティ関連だけでなく一般的な経済動向やこちらから情報提供する上でも広く浅くの情報源としています。数年前ではスマホの画面も小さく、スマホで読もうという気にはならなかったのですが、画面が大きくなったこともあり、新聞の紙面そのままのイメージで読めるようになっています。最近ではユーザーインターフェースもだいぶ改善され拡大縮小も楽になり、なんとか片手でも通勤中に読めるので便利ですね。

f:id:users-6h324:20170825182621p:plain


雑誌
IT分野の情報源としては多くの情シスの方も読んでいる日経コンピュータを選んでいます。この雑誌で「動かないコンピュータ」という連載記事があります。なんだかんだ言っても、他人の失敗には多く学ぶ点があり、興味深く読ませていただいています。SEとしては「システムダウン」とか「全面障害」などの言葉がビビっときます。もし自分が担当してたらと想像する一方、どう解決したのかと顛末が気になります。また、大きな業務影響のある障害の記事が多いのですが、身近なところではマックの記事がありました。店頭でゴメンナサイレターが長期間貼り出されていたことを知っている方も多いと思います。正直放置しているのかと思いましたが、そうではなかったようでこの記事でトラブルの内容がわかりました。WannaCryの亜種に感染していたようです。 

f:id:users-6h324:20170825182715p:plain

 

セキュリティー関連

これは見ていること前提でお客様と会話が始まりますので、定期的に目を通しています。

f:id:users-6h324:20170825183444p:plain

 

今後のIT動向
新聞は世間一般の情報、日経コンピュータはIT分野の過去あるいは現在の動向についての情報ですが、今後の動向という意味ではガートナーの記事を情報源としています。無料の記事しか読んでいませんが、ある程度参考になります。

 f:id:users-6h324:20170825183015p:plain

 

（⭐︎か）問題解決へのアプローチ

問題解決（障害）について

ITエンジニアには障害対応がつきものです。

ここでは、我々が問題解決を行う場合について整理してみました。

1. PD/PSI
1.1 PDとはProblem determination　で、問題はハードウェアかソフトウエアか　のプロセスで切り分け後はそれぞれの専門家が対応します。
1.2 PSIとはProblem Source Identification で、PDでソフトウェアが原因である場合に、OSかミドルウェアかアプリケーションか　を切り分けます。
その後はそれぞれの専門家が対応することになります。

2.問題解決のアプローチ：フローチャートか仮説検証か
問題解決には大きく分けて２つの方法があるように思います。
既知の問題であれば、フローチャートによる問題解決は有効ですが、複数の原因が絡むような未知の問題には仮説検証法でないと対応は難しいでしょう。

2.1 フローチャート　または枝分かれ問題解決法
　例：　Aのランプはついているか？
　　　　　Yes:　Bのランプを見る
　　　　　No:　Cのランプを見る
と、問題解決の手順に沿って原因を突き止める方法

利点：基本的なスキルはあるが、その分野には詳しくない場合でも問題解決ができる
欠点：原因究明まで時間がかかることが多い
　　　手順を作成するのが手間がかかる、また技術変更により手順の修正も発生するためきちんと保守しないと役にたたない手順となる

当職が経験した実例：

入社して数年頃、あるお客様で作業をしていたところ、知り合いのCEさんがIBM3540の修理にきました。現象はReadyにならない　とのこと
IBM3540 (8 inch Diskette Reader)はその当時でももうあまりない機械でその技術員も修理は初めてのようでした。
やおら保守マニュアルを引っ張り出し、手順に沿ってPD/PSIが開始されました。

１）現象確認　再現性あり
２）手順に沿って、ある接点の波形をオシロスコープで測定　→　波形が出てない
３）手順に沿って、センサー部を視認　→　ほこりが溜まっていた
４）手順に沿って、清掃を実施
５）オシロスコープで再度波形を確認　→波形が正常
６）ディスケットを挿入　→　Ready　となる　修復完了

現場でオシロスコープを使用してPDを行うのを見るのは初めてでしたが、手順が完備されていればIBM3540を知らなくてもオシロスコープの使用法がわかれば解決できるのだな　と感心しました。

2.2　仮説検証法
既知の問題であっても、経験が豊富なエンジニアであればこちらの方が解決までの時間は早いでしょう。複雑な問題でフローチャートではたどり着けないような問題へのアプローチではこちらが有効と思います。

１）問題を特定する　何が問題か、何を解決すべきか　を特定する
２）情報を集める　どのような現象か？　最近どこか変更を行ったか？　発生条件はあるのか？
３）問題の仮説を立てる　XXが不足している？　YYのバージョンが古い？　ZZの手順が正しくない？　
４）３）を検証するための調査を行う
　→　調査結果が仮説と合わない　＝＞　別の仮説を検証する
５）仮説が立証される　＝＞　対策を施す

利点：結果を得るまでの時間は短い（一般的に）
欠点：問題解決にあたるには、ある程度の経験やスキル、及びアプローチ方法を理解する必要がある。

次は、この仮説検証法についてもう少し深く説明してゆきます

（前田）[初心者向け] WAS Liberty お役立ち情報・・・性能情報取得

WAS

0. はじめに
WAS Liberty は2012年にリリースした WAS V8.5 から新しく提供されたランタイムです。
従来の WAS traditional と比べて軽量なランタイム、高速な起動、シンプルなサーバー構成といった特徴があります。
近年、WAS Liberty の採用が増えてきているため、WAS tratitional とは異なる WAS Liberty に関するお役立ち情報を書きたいと思います。今回は WAS Liberty の性能情報を取得する方法です。


1. モニター設定
WAS Liberty で性能情報を取得するには monitor フィーチャーの定義と、モニターしたいコンポーネント対象を server.xml に定義する必要があります。
monitor-1.0 フィーチャーで取得できるコンポーネントは下記のとおりです。

 

・JVM
Heap: 現行 JVM に使用されているヒープサイズ
FreeMemory: 現行 JVM に使用可能な空きヒープ
UsedMemory: 現行 JVM の使用済みヒープ
ProcessCPU: JVM プロセスで使用された CPU のパーセンテージ
GcCount: JVM の始動以降に GC が行われた回数
GcTime: GC 時間の合計累算値
UpTime: JVM の始動以降の時間 (ミリ秒単位)

 

・ThreadPool
ActiveThreads：要求を処理中のアクティブスレッド数
PoolSize：スレッドプールサイズ
PoolName (Default Executor スレッドプールのみをサポートします)

 

・Web アプリケーション
AppName: アプリケーションの名前
ServletName: サーブレットの名前
RequestCount: このサーブレットに対するヒット数
ResponseTime: 平均応答時間 (ナノ秒)
Description: カウンターの説明
RequestCountDetails: 最終タイム・スタンプなど、RequestCount の詳細
ResponseTimeDetails: 取得したスナップショットの数、最小値、最大値など、ResponseTime の詳細

 

・JAX-WS
AvgResponseTime: 平均応答時間 (ミリ秒)
MaxResponseTime: 最大応答時間 (ミリ秒)
MinResponseTime: 最小応答時間 (ミリ秒)
NumInvocations: このエンドポイントまたは操作への呼び出しの数
NumChekedApplicationFaults: 検査されたアプリケーション障害の数
NumLogicalRuntimFaluts: 論理実行時障害の数
NumRuntimeFaults: 実行時障害の数
NumUnCheckedApplicationFaults: 未検査のアプリケーション障害の数
TotalHandlingTime: 合計応答処理時間 (ミリ秒)

 

・セッション
CreateCount: 作成されたセッションの総数
LiveCount: ライブ・セッションの総数
ActiveCount: アクティブ・セッションの総数
InvalidatedCount: 無効化されたセッションの総数
InvalidatedCountbyTimeout: タイムアウトにより無効化されたセッションの総数

 

・ConnectionPool
CreateCount: 作成された接続の総数
DestroyCount: 破棄された接続の総数
ManagedConnectionCount: 使用中の ManagedConnection オブジェクトの数
WaitTime: 接続が認可されるまでの平均待ち時間 (ミリ秒)
ConnectionHandleCount: 使用中の Connection オブジェクトの数
FreeConnectionCount: プール内の空き接続の数

 

設定方法
(1) monitor フィーチャーの定義
server.xml に monitor フィーチャー定義を追加します。
<featureManager>
　<feature>monitor-1.0</feature>
</featureManager>

 

(2) モニターしたいコンポーネントの定義
＜すべてのコンポーネントをモニターしたい場合＞
デフォルトは server.xml に monitor エレメントが定義されていないため、monitor-1.0 フィーチャーでモニターされているコンポーネントはすべてモニターされます。

 

＜一部のコンポーネントをモニターしたい場合＞
一部のコンポーネントをモニターしたい場合は、モニターしたいコンポーネントを monitor エレメントにて定義します。

例：JVM、ThreadPool、ConnectionPoolをモニターしたい場合
<monitor filter="JVM,ThreadPool,ConnectionPool" />

 

 以上でモニター設定は終了です。

 

参考情報：
https://www.ibm.com/support/knowledgecenter/ja/SSEQTP_8.5.5/com.ibm.websphere.wlp.doc/ae/twlp_mon.html


2.モニター情報の取得
モニター設定完了後、モニターされている値を確認する方法ですが、今回は curl コマンドを利用した方法を記述します。
curl コマンドでモニター情報を取得するためには、アプリケーションサーバーへ restConnector 構成、SSL 構成、管理者ロール構成を行います。

 

設定方法
(1) restConnector 構成
server.xml に restConnector フィーチャー定義を追加します。

<featureManager>
　<feature>restConnector-1.0</feature>
</featureManager>

 

(2) SSL 構成
①server.xml に ssl フィーチャー定義を追加します。

<featureManager>
　<feature>ssl-1.0</feature>
</featureManager>


②server.xml に鍵ストア・サービス・オブジェクト・エントリーを追加します。
keyStore エレメントは defaultKeyStore と呼ばれ、鍵ストア・パスワードを含んでいます。
パスワードは平文で入力することも、securityUtility encode オプションを使用してパスワードをエンコードすることもできます。
一番シンプルな構成は下記のとおりです。
<keyStore id="defaultKeyStore" password="keystorepassword" />

 

この構成で鍵ストアと証明書が存在しない場合、アプリケーションサーバーは SSL の初期化中に自動で鍵ストアを作成します。
デフォルトで作成した鍵ストアは有効期限が 365 日となるため、有効期限を延ばしたい場合は securityUtility encode オプションを利用して、鍵ストアを手動で作成してください。

 

③ アプリケーションサーバー作成時にデフォルトで server.xml にhttpEndpoint エレメントが定義されます。httpEndpoint エレメントに httpsPort が定義されていることを確認します。

例：
<httpEndpoint id="defaultHttpEndpoint" host="*" httpPort="9080" httpsPort="9443">

 

(3) 管理者ロール構成
管理者ロールの定義方法はいくつかあります。
以下はquickStartSecurity エレメントを利用した一番シンプルな構成の設定例です。
<quickStartSecurity userName="username" userPassword="userpassword" />

 

参考情報：
https://www.ibm.com/support/knowledgecenter/ja/SSEQTP_8.5.5/com.ibm.websphere.wlp.doc/ae/twlp_admin_restconnector.html

 

アプリケーションサーバーへの設定が完了したら、実際に curl コマンドでモニターされているデータを取得してみます。

 

curlコマンド

curl -s -u username:userpassword -k https://hostname or IPaddress:WAS https port番号/IBMJMXConnectorREST/mbeans/ObjectName/attributes/属性

 

上記コマンドでモニターされている情報を取得します。

例として下記にThreadPoolのPoolSizeを取得する場合とConnectionPoolのCreateCountを取得する場合を記載します。

 

例1：ThreadPoolのPoolSizeを取得する場合

■実行コマンド例
curl -s -u admin:password-k https://localhost:9443/IBMJMXConnectorREST/mbeans/WebSphere%3Atype%3DThreadPoolStats%2Cname%3DDefault%20Executor/attributes/PoolSize

※補足

username＝admin
userpassword＝password
hostname＝localhost（ローカルで実行する場合）
WAS https port番号＝9443
ObjectName＝WebSphere:type=ThreadPoolStats,name=Default Executor　（":"（コロン）＝%3A、"="（イコール）＝%3D、","（カンマ）＝%2C、" "（スペース）＝%20・・・UTF8の16進数表記）
属性＝PoolSize

 

■出力結果例
{"value":"50","type":"java.lang.Integer"}

 

例2：ConnectionPoolのCreateCountの場合

■実行コマンド例
curl -s -u admin:password-k https://localhost:9443/IBMJMXConnectorREST/mbeans/WebSphere%3Atype%3DConnectionPoolStats%2Cname%3Djdbc%2FTESTDB/attributes/CreateCount

 ※補足

username＝admin
userpassword＝password
hostname＝localhost（ローカルで実行する場合）
WAS https port番号＝9443
ObjectName＝WebSphere:type=ConnectionPool,name=jdbc/TESTDB　（":"（コロン）＝%3A、"="（イコール）＝%3D、","（カンマ）＝%2C、"/"（スラッシュ）＝%2F・・・UTF8の16進数表記、JNDI名がjdbc/TESTDBの場合）
属性＝CreateCount

 

■出力結果
{"value":"1","type":"java.lang.Long"}

 

定期的にモニターされている情報をテキストファイル等へ書き出したい場合は、スクリプト等を作成して、valueの値を書き出してください。

(萩原)IT初心者向けおすすめ書籍3選

こんにちは。私は情報系の知識がほぼほぼ無い状態でIT企業である弊社に入社してしまいました。どれくらいわからないかというと、「どうしてMacにWindowsも入れられるのか不思議でしょうがない」「サーバーといえばあの大きなやつだと思うが、どうして個人でレンタルできるのか？？家に置くの？？」レベルでした。恐ろしいですね。

現場に出て仕事をしながら技術や製品について覚えて行くわけですが、やはりいきなり専門的なことを覚えようとしても、なかなかぴんときませんでした。当然といえば当然で、ITについて、何が揃っていれば動くのか？システムを構築するには何が必要なのか？といった前提が無いため、それがどうして必要なのか腑に落ちなかったのです。そこで、そもそもITとは、コンピュータとは、ネットワークとは、といった基礎を理解するためにITについての本を読んだりしていました。そこで「お、これはわかりやすいな！」と思った本をご紹介します。

1. ビジュアル版　コンピューター&テクノロジー解体新書

コンピューター&テクノロジー解体新書

コンピューター&テクノロジー解体新書

ビジュアル版ということで、普通の読み物というより図説のような感じです。
コンピューターやIT技術の発展をわかりやすい図と共に追っていきます。言葉だけではイメージが掴みにくい専門用語も、イメージ図があることで直感的に理解できます。
フルカラーでイラストが格好いいので、ぱらぱら見るだけでも楽しいです。
扱う範囲が広く、スマートフォンやテレビの仕組みなども扱っています。日常で使っているけれど、そういえばどうやって動いているんだろう？という疑問に答えてくれる本です。


2. イラスト図解式 この一冊で全部わかるサーバーの基本

イラスト図解式 この一冊で全部わかるサーバーの基本

イラスト図解式 この一冊で全部わかるサーバーの基本

「サーバー」「ネットワーク」など、もう少し分野を限定してについて詳しく知りたい場合はこちら。上記はサーバーを扱っていますが、このほか同シリーズで「ネットワークの基本」「クラウドの基本」「Web技術の基本」「セキュリティの基本」などがあります。
イラスト図解式ということで、こちらもイラストが豊富で理解が進みます。およそ半分のページが「イメージでつかもう！」というコーナーになっており、文章による説明と合わせて理解を助けるものになっています。
さくさく読むことができるので、まずとっかかりの入門書としてよいのではないでしょうか。私はインフラ周辺を勉強する必要があったため、大変助かりました。

3. コンピュータはなぜ動くのか～知っておきたいハードウエア＆ソフトウエアの基礎知識～

コンピュータはなぜ動くのか?知っておきたいハードウエア＆ソフトウエアの基礎知識?

コンピュータはなぜ動くのか?知っておきたいハードウエア＆ソフトウエアの基礎知識?

コンピューターというと目の前のPCを想起する人が多いかと思いますが、スパコンもコンピューターだし、スマートフォンもコンピューターですよね。様々な形態のコンピューターがありますが、その共通点はなんなのか？という最も根本的なところから説明してくれる本となっています。コンピューターはプログラムで動きますが、そのプログラムはどのような流れで理解されているのか、アルゴリズムとは、データ構造とは…という形で説明されていきます。ハードウェア、ソフトウェア、アルゴリズム、データベースなど、各論で学べるものは多いのですが、それぞれがどのように関係しているのかを説明している点がわかりやすいなと感じました。構成的にはプログラミングなどのややソフトウェア寄りな章が多いです。

以上、各技術分野について詳しく書いてある本は沢山あると思いますが、そこに入る前にまずイメージ概要を掴めるものをあげてみました。
まだまだ勉強中のため、おすすめ書籍等あれば教えてください！

(kin) AIXにおけるパスワードハッシュの作成方法

　AIXで色々なパスワードのハッシュの作成方法について書こうかと思う。単純に書くのであればコマンド1つ書いとけばいいのだが、まぁそれだと記事にならないので、その前提なども少々。
　まずはパスワードについての基本から。
　パスワードというものは基本的にシステム上に平文で保管されることは少ない、今となってはほぼないといってもよい。流出に対しての耐性を高めるため。パスワードは基本的にシステム内にハッシュ値として保管される。よく暗号化パスワードなどと表現されているが、基本パスワードとハッシュ値は1対1で且つ不可逆である。すなわちハッシュ値からパスワードを復号、もしくは演算することはできない。よって、パスワードハッシュが流出した場合、いわゆるプルートフォース(総当たり)によるパスワード解析にかけられることになる。そのため、パスワードのハッシュアルゴリズムはこの演算の際に如何に多くのCPUを使わせるかが重要となってくる。大量の演算により結果がでるまでの時間を非現実的にまで引き延ばすことでパスワード解析を事実上不可能にするのである。
　そのため、パスワードハッシュのアルゴリズムはCPUの進化と共に複雑にならざるをえない。当初Crype(3DES)しかなかったアルゴリズムがMD5になりSHA2になっているのも、CPUの進化やレインボーテーブルなどの解析方法の進化により単純なアルゴリズムではパスワード解析が現実的になってしまったためである。現在ではSHA1までは既に危険とされSHA512もしくは精々がSHA256辺りまでが当たり前となっている。
　Linuxでは大分前からデフォルトがSHA512(type6)にかわっており、少し前まではツール類が追い付いておらずハッシュ計算に苦労したが、今では普通にcrypt関数でサポートしている。しかし、AIXでは何故か未だにデフォルトがCrypt(3DES)。非常に不思議だがMWとの関連などで仕方ないのだろうか? ちなみにWindowsも長い間LMハッシュが生きていたし、いまだNTハッシュ(MD4)が生きている辺り、独自実装の世界はこの辺りの進化が遅いような気がする。
　MW側での対応が遅いのは将にハッシュアルゴリズムの問題のように思う。表題のパスワードハッシュの作成方法とも絡むのだが、ユーザーの認証処理などを行う場合、UNIX系では割と入力されたパスワードを自分でハッシュ化するような実装が多かったように思う。今では大部分がMW経由だったりAPI経由だったりするため、ユーザーとパスワードをAPIなどに渡してOK/NGを判断しているのが大半かと思うが、そうではなく、入力されたパスワードをハッシュ化して、システムに保管されているパスワードハッシュと比較するのである。当時はその実装方法によるメリットは色々あったわけだが、ハッシュアルゴリズムが入れ替わる現在ではほぼ致命的である。アプリケーションが自身でハッシュアルゴリズムに対応する必要があるため、新しいアルゴリズムには中々対応できない。しかも独自実装。MW側の対応が中々進まないのも仕方ない気にはなる。

　ここまで基本的な話を書いてきたが、この辺りからが本番。
　まずは、パスワードハッシュの独自実装とは何のことか? これまで書いている通り、基本的なアルゴリズムは共通といってよい。SHA2にしろMD5にしろ公開されており同じものである。違うのはパスワードハッシュのフォーマットである。パスワードハッシュには必須の情報が幾つかある。ハッシュのアルゴリズムが何かと、ハッシュされた値と、ソルトである。
　ソルトとは文字通り、各個人の好みにより味つけを変えるための塩のこと、すなわちハッシュ値にバリエーションを持たすための乱数である。前記のようにパスワードとハッシュ値は1対1、ソルトがないと同じパスワードは同じハッシュ値となる。片方のパスワードを知って、別のユーザーのパスワードを推測できるようでは困るのである。そのため、パスワードハッシュを生成する場合は、パスワードと乱数のソルトを元にしてハッシュ値を計算することにより、同一のパスワードでも別のハッシュ値とするようにする。
　パスワードハッシュのフォーマットは元々全UNIXで共通であった。アルゴリズムが1つしかなかったため、必ず頭2桁がソルトで、残りがハッシュ値の13桁となっていた。しかし、様々なアルゴリズムが存在する現在、そのアルゴリズムを表すキーワードを何にするか?どのような順番にするか?などがシステムによって違うのである・・・というかAIXだけ違う・・・。

　Linuxの場合、パスワードハッシュのフォーマットは以下のようになる。

　　　$type$ソルト$ハッシュ値

　「$」が区切り文字で、最初がアルゴリズム、次がソルト、最後にハッシュ値である。例えばSHA512の場合、以下のようになる。ちなにみHP-HXもSolarisも同様。


　　　$6$1234567890123456$YfUD.j5zIFtfV6VgikPof2dzCCCZwL2YDraBX4HXi.J7iNq24667epYUCZGxExqOmHTnPWybzfYaynT29vKXJ/

　Type6がSHA512を表し、Type5はSHA256、Type1がMD5を表す。分かり易いようにソルトは全て並びの数字にしている。
　ではAIXはというと以下である。

　　　{ssha512}06$1234567890123456$/lorQE8P98Iw0lzrzOubFgMqe/p0tcWeC99jbL2KcWnK5jKcXx0WPYqo2aILdeH9Nrwg8A6p/InBnWiqBfWW..

　フォーマットもハッシュ値も全く違う。しかもこのフォーマットはアルゴリズムによって違う。SSHAの場合は以下のようなフォーマットとなる。

　　　{アルゴリズム}ストレッチング回数$ソルト$ハッシュ値

　ストレッチング回数とはハッシュを繰り返す回数のことで、前記のように、よりCPUを消費させることを目的にした実装である。ハッシュした値を更にハッシュし、この数分演算を繰り返すことで同一のアルゴリズムで数倍のCPU消費を強制することができる。ちなみにsmd5の場合、ストレッチング回数の指定はなく、ソルトは8桁となる。
　何故こんなに違うのかというとLPA(Loadable Password Algorithm)のせいである。LPAとは上記のようなパスワードハッシュのモジュールを独立させることで、システムに対してのアルゴリズムの追加、変更を容易にしようというもので、sshaをサポートするモジュールとsmd5をサポートするモジュールは全く別なのである。そうはいっても標準化しろよ、といいたくはあるが・・・
　様々なアルゴリズムが存在し、更に増えていくであろう現在、こんなにバラエティにとんだアルゴリズムをアプリ側で独自にサポートするのはさすがに無理がある。私自身、システム管理者として振出したパスワードの確認などでパスワードハッシュを作りたいと思うことが割とあるのだが、どうやって作ったものか悩んでいた。Linuxではフォーマットを標準化してcryptでもサポートしているが、AIXでもサポートしないかと思っていたら、サポートされていた。しかし、中々に情報がない上に、間違っていたり、不安定だったり・・・未だ不明な部分も多いのだが、ちょっと情報公開しておこうかと思った所以である。
　crypt関数はAIXの提供するC言語のライブラリ関数である。非常に伝統的な関数であり、元々は引数にパスワードと2桁のソルトを指定すると13桁の3DESのハッシュ値を返してくれるものであった。それが、LPAのその他の様々なアルゴリズムをサポートするようになったのである。とはいえ、それだけでは余り嬉しくはない。プログラムを書くのはいいのだが、様々な環境やシステムを弄る立場上、どこでコンパイルしたらいい? という問題が常に付きまとう。もっとどこででも簡単にと思っていたら、あった。perlである。perlにはシステムのAPIそのままの関数が様々にある。cryptも伝統的な関数なのでperlでもサポートされ、以前はよく使っていた。恐らくはそのままシステムのAPIを呼び出しているだけと思われたので、ためしにC言語のcrypt関数と同様のソルトを指定してみたところ、サポートされていた。
　perlでcrytを使う場合の基本的な使い方は以下の通り。ほんの1行、スクリプトにするまでもない。
　
　　　# perl -e '$hash=crypt("password","salt"); print "$hash\n";'
　　　sa3tHJ3/KuYvI

　デフォルトの挙動では3DESの13桁のパスワードハッシュが生成される。
では、ssha512の場合はどうなるか?

　　　# perl -e '$hash=crypt("password","{ssha512}06\$1234567890123456\$"); print "$hash\n";'
　　　{ssha512}06$1234567890123456$/lorQE8P98Iw0lzrzOubFgMqe/p0tcWeC99jbL2KcWnK5jKcXx0WPYqo2aILdeH9Nrwg8A6p/InBnWiqBfWW..

　みごとにssha512のパスワードハッシュが生成された。上記で「$」の前に「\」があるのは「"」で囲っているためエスケープしてやる必要があるためである。
ちなみにここでソルトを省略した場合、乱数のソルトを自動で生成してくれる。

　　　# perl -e '$hash=crypt("password","{ssha512}06\$"); print "$hash\n";'
　　　{ssha512}06$sL.WSbJpW2xdD2G5$FrvXYETBde5oGMkSc9VWSNwmPaLkitpGUlYf5pcKRNmM3a8aDbCKk9dtf83qBs2GrKQzbUjytXXIODNWgy.s..

　ここで指定できるアルゴリズムは以下のファイルに指定されている。

　　　/etc/security/pwdalg.cfg

　ここまでは綺麗に動いているようにみえるが、何が不安定なのか?

　LPAの弊害なのか、元々のcryptの仕様の問題なのか、バグなのか、全てのフォーマットエラーを無視して伝統的なcryptとして動くのである。例えばストレッチング回数。サポートされるのは4-31回だが、4回と指定してみる。

　　　# perl -e '$hash=crypt("password","{ssha512}4\$01234567890123456\$"); print "$hash\n";'
　　　ZOb9qQRD8CKi6

　なぜか13桁のパスワードハッシュが返る。これだけ見ると全くLPAをサポートしているようには見えない。しかし「4」ではなく「04」と指定すると。

　　　# perl -e '$hash=crypt("password","{ssha512}04\$01234567890123456\$"); print "$hash\n";'　　　{ssha512}04$01234567890123456$3OUe2I2xLl/nokoAYMBZG.Pprz3b/NZEVk21.mdzRyIOfCPWO56wXdFUFmKMidl.X5ZOsmqXhKOBjH6w8mmG..


　きれいにssha512のパスワードハッシュが返ってくる。また、cryptのマニュアルを見るとアルゴリズムに{SMD5}を指定できると記述されているので、{SMD5}を指定してみると。

　　　# perl -e '$hash=crypt("password","{SMD5}012345678\$"); print "$hash\n";'
　　　sa3tHJ3/KuYvI

　13桁のパスワードハッシュとなる。正しくは/etc/pwdalg.cfgの記述の通り、{smd5}。

　　　# perl -e '$hash=crypt("password","{smd5}012345678\$"); print "$hash\n";'
　　　{smd5}012345678$7nAzsz9W7rm48taUp/QYt.

　基本的にエラーは返してくれず、NULLにさえならない、間違っていると13桁になるだけ。この辺りの挙動は本当に困った。最初にマニュアルから入っていたため、純粋にサポートされていないようにしか見えなかった。しかも一般ユーザーで実行すると、全て13桁のパスワードハッシュに・・・

　　　$ perl -e '$hash=crypt("password","{ssha512}04\$01234567890123456\$"); print "$hash\n";'
　　　JQMuyS6H.AGMo

　AIXのcryptでLPAを利用する場合の注意点は以下の通り。

　　　①rootで実行する
　　　②指定できるアルゴリズムは/etc/security/pwdalg.cfgと正しく一致させる
　　　③ストレッチング回数は2桁で指定する
　　　④エラーは返してくれない。

 

　この辺りに気をつけて使えば非常に便利だと思う。
　ちなみにlinuxのperlでも普通にcryptはサポートされているので、同様にソルトを指定することでType6などのパスワードハッシュを生成できる。但し、ソルトの自動生成はサポートしないようだ。

（鈴木）xCAT管理ノードのインストール手順

xCAT

鈴木です。
前回に続き、今回は、xCATのインストール手順について紹介していきます。

6h324.hatenablog.com
基本的には以下のリンクのとおりなのですが、とっつきにく部分があったり、そもそも英語は読みたくないって方も多いかと思います。

http://xcat-docs.readthedocs.io/en/stable/

そこで本記事では、事前準備からインストール後の初期動作確認までを日本語で紹介するので、興味のある方はぜひトレースしてみてください。

１．本環境の概要

まずは今回のシステム環境について。
今回はxCATのコマンドを発行する「xCAT管理ノード」がインターネットに接続されていない前提で話を進めます。
「xCAT管理ノード」は、インターネットに接続されていないため、xCATインストールモジュールは別途用意するリポジトリサーバ経由でインストールすることにします。

f:id:users-6h324:20170728095113j:plain

また、今回紹介する記事では以下のHW, SW構成で話を進めます。

f:id:users-6h324:20170728094830p:plain

２．リポジトリサーバ準備

今回は、サーバがインターネットに接続されていないケースを想定しているので、xCATモジュール置き場としてリポジトリサーバを準備します。
（リポジトリサーバを別途立てるのは面倒くさい、という場合は、xCAT管理ノードと同一OS上に構成しても問題ありません）
まずは、リポジトリサーバに必要なパッケージをインストールするために、リポジトリサーバ自身（ホスト名：repo01）でyumが使えるようにしておきます。
今回は、RHEL7.2のOSイメージを、/nim/RHEL_7.2/Server配下にコピーしておきます。

RHEL7.2用リポジトリファイルを作成
[root@repo01 ~]# vi /etc/yum.repos.d/server.repo
[Server]
name=RHEL7_Base
baseurl=file:///nim/RHEL_7.2/Server
enabled=1

[root@repo01 ~]# ls /etc/yum.repos.d
rhel-source.repo server.repo

リポジトリを初期化
[root@repo01 ~]# yum clean all

これでリポジトリサーバ自身（ホスト名：repo01）でyumを使ってRHEL7.2 OSパッケージをインストールできるようになります。
さっそく、リポジトリサーバに必要なパッケージを以下のとおりインストールしていきます。

[root@repo01 ~]# yum install createrepo

[root@repo01 ~]# yum install httpd

再起動時にhttpdが自動起動するように設定しておきましょう。
[root@repo01 ~]# systemctl enable httpd

httpdを起動します。
[root@repo01 ~]# systemctl start httpd

念のため、リポジトリサーバ（ホスト名：repo01）と同じNWセグメントからブラウザ上で以下のURLにアクセスできるか確認しておきましょう。

http://リポジトリサーバのIPアドレス/

 

Apacheのデフォルトの公開ディレクトリは「/var/www/html/」なので、xCATインストールモジュール配置用に以下のようなディレクトリを作っておきます。

/var/www/html/yum/x86_64/xCAT

改めて、以下のURLにアクセスすると公開ディレクトリが見えるようになっています。

http://リポジトリサーバのIPアドレス/yum/

 

f:id:users-6h324:20170728111023p:plain

次に以下のサイトでダウンロードしておいたxCATのインストールモジュールを先ほど作っておいた/var/www/html/yum/x86_64/xCATに配置しましょう。

（DLサイトトップ）
https://xcat.org/download.html

[root@repo01 xCAT]# ls -ltr
total 8
drwxrwxr-x 16 root root 4096 Mar 16 01:50 xcat-dep
drwxrwxr-x  2 root root 4096 Mar 16 01:50 xcat-core

ついでに、最初に使った/nim/RHEL_7.2/Server配下のOSイメージも、公開ディレクトリに置いておくと他サーバからもyum installできるようになるので便利です。
私の場合は、/nim/RHEL_7.2/Server配下のOSイメージを/var/www/html/yum/x86_64/RHEL72配下にコピーしておきました。


※rpmパッケージが配置されているディレクトリ上にリポジトリファイルがない場合はyum install時失敗してしまうので、createrepoしておきましょう。

（例）
[root@repo01 ~]# createrepo --simple-md-filenames /var/www/html/yum/x86_64/RHEL72

３．xCAT管理ノード準備

リポジトリサーバの準備が整ったので、さっそくxCAT管理ノード（ホスト名：xcat01)上でxCATインストールしていきます。

まずは事前準備としてリポジトリの設定を行います。
今回は、リポジトリサーバ上のRHEL7.2のOSパッケージ、xcat-core、xcat-depに対してyum installできるように設定しておきます。

RHEL7.2 OSパッケージ用リポジトリ定義

[root@repo01 ~]# vi /etc/yum.repos.d/server.repo
[Server]
name=RHEL7_Base
baseurl=http://リポジトリサーバのIPアドレス/yum/x86_64/xCAT/RHEL72/Server
gpgcheck=0
enabled=1

 xcat-core、xcat-depに対してもyum installできるように以下のようにリポジトリ定義しておきます。

[root@xcat01 ~]# vi /etc/yum.repos.d/xcat2core.repo
[xcat-2-core]
name=xCAT 2 Core packages
baseurl=http://リポジトリサーバのIPアドレス/yum/x86_64/xCAT/xcat-core
gpgcheck=0
enabled=1

[root@xcat01 ~]# vi /etc/yum.repos.d/xcat2dep.repo
[xcat-dep]
name=xCAT 2 depedencies
baseurl=http://リポジトリサーバのIPアドレス/yum/x86_64/xCAT/xcat-dep/rh7/x86_64
gpgcheck=0
enabled=1

リポジトリを初期化
[root@xcat01 ~]# yum clean all

ここまでくれば、あとはインストールするだけ。yum installコマンドを実行してxCATをインストールしちゃいましょう。

[root@xcat01 ~]# yum install xCAT

４． xCAT管理ノード初期動作確認

xCATのインストールが完了したら、以下の要領で初期動作確認を行います。

１．パスを追加
[root@xcat01 ~]# source /etc/profile.d/xcat.sh

２．バージョン確認
[root@xcat01 ~]# lsxcatd -a

３．xCAT用DB初期化
[root@xcat01 ~]# tabdump site

４．起動、停止の動作確認
[root@xcat01 ~]# systemctl start xcatd
[root@xcat01 ~]# systemctl stop xcatd

※起動停止ステータス状況の確認は、以下で確認します。
[root@xcat01 ~]# systemctl status xcatd

ついでに、特に問題ない場合はxcatdがOS起動時に自動起動するように設定しておきましょう。
（xcatはchkconfigから変更する）
[root@xcat01 ~]# chkconfig xcatd on
[root@xcat01 ~]# chkconfig xcatd --list

いかがでしたでしょうか。今回はxCAT管理ノードのインストール手順について紹介しました。
一見、取っ付きにくそうなxCATですが、インストール手順はいたってシンプルなものです。
ぜひ、これを機会に試してみてはいかがでしょうか。

鈴木
２００８年にIBMに入社。
長くエンタープライズのお客様を複数担当。最近はHPC分野を経て金融のお客様を担当。
Unix/Linux系がメインスキル。
最近は、InfinibandやOSS（Zabbix, xCATなど）など社内スキル保有者が少ないレアキャラを目指して活動中。

夜は焼鳥の匂いに誘われて焼酎1杯だけ立ち飲みして帰る純情派のインフラSE。
焼鳥の味付けは塩。

 

（鈴木）サーバ系のインフラSEでxCATは知っていて損はないOSS

xCAT

鈴木です。

私自身、IBMに入社して以来、主にサーバ系のインフラSEとして活動を続けてきました。

インフラSEというと、サーバの電源ON/OFFや、OS導入といった、いわゆる単純作業がつきもの。その割には、サーバの台数が多くなってくるとコストがかさむ箇所も、この作業だったりしますよね。

今でこそ、一子相伝の自動化スクリプトや、Chefなどが出てきましたが、これらはどちらかというとOSより。

HW自体の操作などは、やはり人手が必要になりがちです。

このような状況の中、HWレイヤーからOSレイヤーまで自動化したい方にご紹介したいOSSがあります。

１．xCATとは

「xCAT」は、Extreme Cloud Administration Toolkitの略で、いわゆる「大規模クラスター」向けに開発された管理ツールです。

ここで言う「大規模クラスター」とは、例えば以下のようなもの。

  • HPC（High Performance Computing）
  • オンラインゲーム
  • クラウド　etc...

いわゆる同じ機能や設定を持った大量のサーバ群のプロビジョニング（OS、MWなどの自動導入、設定）や、HW操作を一括管理することを、xCATは得意としています。

なお、公式HPを見る限り、2011年あたりから実用化されているように見えますね。（私自身、xCATが実稼動環境で使われているのを見たのは、この頃からです）

２．xCATができること

公式HPから抜粋しちゃいますが、xCATの主な機能は以下のとおり。（参考：https://xcat.org/ ）

  1. Provision Operating Systems on physical or virtual machines: RHEL, CentOS, Fedora, SLES, Ubuntu, AIX, Windows, VMWare, KVM, PowerVM, PowerKVM, zVM.
  2. Provision using scripted install, stateless, statelite, iSCSI, or cloning
  3. Remotely manage systems: lights-out management, remote console, and distributed shell support
  4. Quickly configure and control management node services: DNS, HTTP, DHCP, TFTP, NFS

上記を見ると分かるとおり、xCATは主要なインフラコンポーネントの大半をカバーしていることが分かります。これだけの機能を全て使いこなせたら素晴らしいだろうな・・・と常々思っている次第（笑）

別記事で紹介する予定ですが、私はxCATで約400台の物理サーバに対してOSプロビジョニングとHW管理する環境を実装しました。

ただ、クローニングや仮想化環境のプロビジョニングまでには至っていないので、今後試す機会があれば、それも随時紹介していきたいと思っています。

３．xCATの知識を身に着ける前に覚えておきたい推奨知識

xCATは、HW管理とプロビジョニング機能を併せ持ったOSSであることを紹介しました。

HW管理の箇所についてはコマンドと機能を覚える程度なので、そこまで深い知識は必要ありません。

一方で、プロビジョニング機能に関する知識を身に着けていこうとすると、事前に知っておいた方が理解が早まる知識があります。 それが、「キックスタートファイル（ksファイル）を使ったOSのネットワークインストール（NWインストール）」。

例えばRHEL系のOSインストールなどの場合は、事前にどのような設定でインストールするのかを記述した「ksファイル」を作成しておくことで、いちいちインストール画面での入力を必要とせず、OSを自動インストール、自動設定することができます。

また、NWインストールすることで、CD/DVDでインストールする時より遥かに早い時間でOSインストールを完了できます。

これを合わせ技として実装したものが、、「キックスタートファイル（ksファイル）を使ったOSのネットワークインストール（NWインストール）」です。

実は、xCATもプロビジョニングの際は、同じような原理で動作します。（若干、設定箇所が違うくらい） 。

なので、もし時間がある方は、「キックスタートファイル（ksファイル）を使ったOSのネットワークインストール（NWインストール）」についても知識を得ておくと良いかもしれませんね。 （もしかすると、私の方でこの記事も書く・・・かも）

４．おわりに

今回はxCATについて以下を紹介しました。

  • xCATができること
  • xCATの前提知識

なお、xCATについてWeb検索しても、公式HP以外あまり詳しい情報は出てこないですね。マイナーOSSってことですかね（笑）

とはいっても、自動化を推進したいと思っている方にとっては、覚えておいて損はないスキル。このブログを通しても、基本的な設定方法や使い方を紹介していきたいと思います。

 

この記事の執筆者 ：鈴木

２００８年にIBMに入社。 長くエンタープライズのお客様を複数担当。最近はHPC分野を経て金融のお客様を担当。 Unix/Linux系がメインスキル。 最近は、InfinibandやOSS（Zabbix, xCATなど）など社内スキル保有者が少ないレアキャラを目指して活動中。 夜は焼鳥の匂いに誘われて焼酎1杯だけ立ち飲みして帰る純情派のインフラSE。 焼鳥の味付けは塩。

（中上）あまり知られていない気がする、vSphere ESXiのディスクI/O改善方法

VMware

こんにちは、IBMの中上です。

入社5年目で、入社以来、現場SEとして、主にVMware、Linux、Windowsを中心にシステム設計・構築・運用などを担当しています。

特に、VMwareとLinuxを触る機会が多い気がします。
（※単に、Windowsに関しては比較的お客様でも触れるからというのが背景です）

今回は、VMware社が提供する中心製品であるvSphere ESXiのちょっとしたTipsを紹介しようと思います。

1.「ディスクI/Oが重い気がする」

入社以来、特に運用フェーズの支援をしていると、よくこんなお問い合わせの電話を受けます。

分かります、もっさりとしていると、それだけですごくストレスですもんね。

こういうパフォーマンス問題は厄介なもので、エラーらしいエラーは出ていないけれども「普段に比べてなんとなく処理が遅い気がする」という事象の表れ方をします。

そのため、発生している事象に対する切り込み方が非常に難しい。

大抵、電話をかけてくださる情報システム部の方も「困っているんです…」と困り顔が目に浮かぶような声音であることが多い気がします。

 

一般には、こういうパフォーマンス問題の時には、仮想OS、物理ホスト、ストレージそれぞれの観点で、普段とは異なるリソース使用状況が生まれていないか、一つ一つ潰していくことになります。

この切り分け方法を網羅的に書くことはそれ自体がかなり難しいですし、環境や設計にも依存しますので、ここでは割愛します。

 

さて、ディスクI/Oに関しては、問題が余計に面倒な様相を呈してきます。

その背景としては、主に2点あると思っています。

  1. 目に見えにくいため、発見が遅れがち
  2. 発見されても、速攻で対処できるとは限らない

1. に関しては、経験則として、ディスクI/Oを常時監視しているような環境をあまり知りません。レスポンスタイムの監視というのがなかなか難しいというのがあると思います。

2. に関しては、ボトルネックが見つかったとしても、チューニングが難しかったり、原因次第ではより高速なストレージに変更するより他ないなどのケースがあり得えます。

極端な話、仮想OSのCPUやメモリがリソース不足を起こしているのであれば、足してあげれば良いのですが、ディスクに関してはそういうわけにもいかないことがあるのですよね。

予防策としては、性能要件を十分に定めて要件を十分に満たすストレージを使用する、共有ストレージを共有しすぎない、といった根本的な計画の部分に関わることになると思います。

 

2. ESXiのディスクI/O改善Tips

ESXiから外部ストレージに対するI/Oに話を絞ります。

外部ストレージ側が対応していれば、ESXiの外部ストレージへのパス選択方法として「ラウンドロビン」を選ぶことができます。
（※少なくとも弊社のミッドレンジ以上の製品は大半が対応している印象です）

ラウンドロビンがもたらす効果として、全てのアクティブなストレージパス間での負荷を分散できます。

他のパス選択ポリシーとして「最近の使用」「固定」などがありますが、これらとは異なり、論理的には全てのアクティブパスの帯域を使用できることになります。

 

ただ、VMwareのラウンドロビンポリシーに関しては、以下の特徴があります。

1 つのパスは、特定の量のデータが送信されるまで選択されたままで使用されます。その量に達すると、PSP ではリスト内の次のパスが選択されます。

で、このパスが切り替わる基準が、デフォルトでは、ディスクI/O 1000回になっています。

これがなかなかの問題で、例えば、特定のパスが8Gbps＝1GBだとした場合に、I/O 1000回以内に1GBが送受信されると、一部のI/Oが待機させられることになるのです。

これでは、複数ストレージパスを持たせ、負荷分散を図ったにも関わらず、逆にI/O遅延を引き起こす可能性があります。

 

この切替基準は、ESXiの再起動等を伴わず変更が可能です。

例えば、Queue Depthのようなパラメータは、ESXiの再起動が必要になりますので、仮想マシンの退避などの調整がどうしても発生してしまいます。

それに比べれば、かなり融通がききやすいチューニングポイントとなります。

 

個人的には、このデフォルト値については、ちょっとその意図が分からないなあというのが正直なところです。

実際に、以前私が担当していた案件にて、ディスクI/Oが非常に激しい仮想サーバのパフォーマンスチューニングの中でこの設定変更を入れることで、ディスクI/O処理を改善させることができました。

 

詳細は、以下のKBを参照して下さい。

kb.vmware.com

 

3. 前提・留意点

まず、そもそもとして、ラウンドロビンが構成可能なストレージであることを確認する必要があります。

確認の際には、VMwareを触っている人であればお馴染みだと思いますが、VMware Compatibility Guideのサイトでご確認下さい。

VMware Compatibility Guide - System Search

 

また、KBの中にも記載がある通り、ストレージベンダー側がこの構成を推奨するかは確認が必要になります。

 

既に本番運用中の環境の場合、それまでは待機させられていたI/Oがストレージに集中する可能性があるため、変更した直後から、ストレージ側への負荷が高くなり、逆にレスポンスタイムを悪化させてしまう可能性もあるでしょう。

必ずしも1000→1に変更する必要はなく、少しずつ数値を下げていくような形でリスクヘッジすることも検討したほうが良いと思います。

 

変更の際には必ずesxtopを確認しましょう。

ディスクデバイス画面またはディスクアダプター画面で、IO数、帯域使用量、レスポンスタイムをリアルタイムに観察した方が良いでしょう。

なお、上で少し言及した案件の際には「KAVG/cmd」の値がチューニングによって改善されました。

 

4. おまけ（esxtopについて）

esxtopは、ESXiのパフォーマンス状況をリアルタイムに確認できるツールです。

ディスクI/O、特にレスポンスタイムに関しては、以下のような区別がなされています。

  • GAVG　…　ゲストOSから見たレスポンスタイム
  • KAVG　…　VMKernelで消費される時間
  • DAVG　…　ストレージデバイスで消費される時間

つまり、GAVG = KAVG + DAVGという式になります。

今回のチューニングで効果が出るのは、恐らくKAVGだと思います。ストレージパスの帯域が飽和することで、VMKernelの中でI/Oが待機されることになるので、その消費時間はKAVGの値に加算されるものだと思われます。

逆に、DAVG側が高い値を取っている場合は、今回のチューニングはあまり効果を与えないことだと思います。

この場合は、残念ながらストレージ側が性能限界ということになります。

 

5. 最後に

社内で設計検討する際に「パス選択ポリシーはラウンドロビンで」という点までは話題に上ることは多いのですが、流石に上のチューニングポイントについてはあまり話に聞いたことがありませんでした。

「ラウンドロビン＝I/O 1回毎に次のパスを使用する」というようなイメージを持ちかねませんので、ちょっと気をつけたいところですね。

 

それでは、引き続き、次の投稿をお楽しみに！

 

この記事の執筆者：中上

2013年にIBMに入社。エンタープライズ系のお客様を主に担当するインフラSE。メインスキルは、VMware、Linux、Windowsなど。入社時の技術研修で勉強したSystem xシリーズは、プロジェクトに配属される頃にLenovo社に売却される。以来、自社製品に殆ど触れることなく気づけば5年目。

初対面の人には「神経質そう」「理系っぽい」と言われがちだが、根っからの文系人間。
趣味は音楽。入社以来、年1本のペースでギターが増殖中。

（鈴木）IBMで働く現場SEメンバーがはてぶ（ブログ）始めたよ

このブログについて

IBMの鈴木です。IBMの現場SE部門でインフラSEを10年ほどやっています。

このたび、うちの部門の試みとして、「IBMの現場SEが培ってきた様々な情報」をこのブログに書いていくことにしました！

 

1. IBMの現場SEがこんなことを書いていく

どんなことを書いていこうか・・・私は同じ部門のメンバーと話し合いました。

その結果・・・

あれこれ出すぎてまとまりませんでした（笑）

例えば以下のような内容です。

  • テクニカルな知識の公開
  • 何かに対するレビュー
  • 成功談・失敗談
  • いちSEとして、いちIBMerとして、いち人間として言っておきたいこと
  • お勧めのお店紹介


などなど・・・種々様々、雑多に書いていく予定です！おそらく、書く人間によって書くカテゴリも書きっぷりも全然違ってくると思います。

はっきり言って私も誰がどんな記事を書くのか想像もつきません（笑）しかし、「誰かの役に立てれば」という思いは、私たちの唯一の共通認識です。

2. IBM 現場SEがブログを始めた理由

なんでまたIBMのSEが、しかも複数人でこのようなブログ活動をするのか？

 それには、私たちの部門にこんな課題があるからです。（部門といっても、10数人くらいの最小単位の集まりですが）

 

  • 現場SEの知識をアウトプットする機会がない（本当はあるんだけど、積極的にアウトプットしないことが少なかれある）
  • 誰がどんなスキルや考え方をもっているのか、同じ部門内ですら周知できていない
  • ブログって何か面白そうじゃん！やってみようぜ！

まぁ、同じ部門と言っても全員で同じ仕事をするわけではないので、実はプロジェクトメンバーより絡みが少なかったりするわけです。（「SEあるある」ですねｗ）

 そこで、ブログという情報媒体を活用することで、楽しみながらこの課題を乗り越えていこうと思っています。

3. このブログの目指すところ

このブログを書くメンバーは私も含め、SEです。なので、同じような仕事をしているSEの方に、少しでも役に立つ情報を提供できたら、こんなに嬉しいことはありません。

 

これが、このブログの目指すところです。

 

もしかすると、記事の内容が読み手に正確に伝わらなかったり、難しいと感じさせてしまうかもしれません。 そういうのをブログを通して少しずつ改善していくことで、我々も成長できると思っています。

 同時に、我々自身が抱えている課題（アウトプット機会が少ないなど）も、このブログに記事を投稿していくことで改善できたらいいなーと緩めに期待しています。

4. 投稿頻度は月に数件を目標

本当は、毎日投稿できるといいのですが、そこまでの体力がありません（笑）

 おそらく、月に数件程度の投稿頻度でゆる～く運営していくことになると思います。

 その分、違う個性の人間が、イロイロな記事を書いていく予定なので、ゆる～く見ていただければ幸いです！

 ということで、「IBM現場SEのITな日々」の開設にあたり、私、鈴木より簡単なブログの紹介をさせていただきました。

今後とも当ブログをよろしくお願いします！

 

この記事の執筆者　：鈴木

２００８年にIBMに入社。長くエンタープライズのお客様を複数担当。最近は金融系。純情派のインフラSE。Unix/Linux系がメインスキル。 最近は、InfinibandやOSS（Zabbix, xCATなど）など社内スキル保有者が少ないレアキャラを目指して活動中。

仕事柄（？）、血液型をA型に見られがちだが、弩級のB型です。 趣味はカメラ。IT知識よりカメラの方が詳しいのでは？という説もあり。