ao-log

インフラ系ITエンジニアのメモ帳です。

書籍レビュー『BABOK超入門』

ビジネスアナリシス知識体系ガイド(BABOK:A Guide to the Business Analysis Body of Knowledge)について、筆者なりの視点で実践知識を交えて解説した本。超入門という題名にある通り、BABOKガイドを読む前の基礎体力づけが本書の位置づけ。

あるプロジェクトの立案から、稼働後の評価まで、ビジネスアナリストがどのように行動するべきかが解説されています。ビジネスアナリシスとは何かから始まり、ステークホルダの洗い出し・把握、コミュニケーション(伝達手段・表現方法)、情報の承認・変更プロセスの管理、要求の引き出し、要求実現のための方策の策定・合意の形成、ITベンダへの発注・ベンダからの提案内容の評価、システム稼働後のソリューション評価まで。

筆者の体験や、実際に起こりがちな問題についてよく書かれています。例えば、決定された事項が、プロジェクトに関係ないと思われていた役員に、突如ひっくり返されるなど。
また、ビジネスアナリシスを進めるにあたり、様々なステージにおけるチェックリストがあります。漏れの確認にはチェックリストが役に立ち、BABOKの活用のしどころだと思います。

書籍レビュー『すべてわかる仮想化大全2013』

仮想化大全2013読了。ついでに2009と読み比べてみました。

仮想化大全2009の発行は今から4年くらい前ですが、内容は今となっては随分と古いものに感じられました。VMware Infrastructure のバージョンは V3.5, VMotion もまだ Enterprise 版のみ、update Manager もまだ実験的なサポートの段階。当時はまだ普及期まで至っていない状況で、本の内容もサーバ仮想化、クライアント仮想化がメイン。

これが2013年になり、サーバ仮想化はもはや当たり前、プライベートクラウド作成、管理を支援するソフトもだいぶ充実してきた印象です。OpenStack による IaaS 構築の記事が好印象でした。各コンポーネントの説明だけでなく、内部での動作原理、設定ファイルの書き方や投入するコマンドも例が多く、個人的にはかなり楽しめる内容。

また、近年はSDN(software defined network) が注目度を浴びていて、本屋でも OpenFlow の文字が表紙に書かれた書籍、雑誌を多く見かけるようになりました。本書でも 1 章分を割いていますが、まだ黎明期なのか、あるいは経営よりの人をメインターゲットにしているためか、技術面では表面的な内容にとどまっている印象です。最近、日経 NW で OpenFlow の連載をしているので、そちらを見てくださいって事かもしれないです。OpenFlowはVLANタグ数の問題や、帯域の有効活用につながる点などインパクトが大きいですが、どのくらいの勢いで伸びていくのかは、未知数の段階。ところで、Data Center 間トラフィックを OpenFlow でさばいている Google の発表事例(「Open Networking Summit 2012」にて)が一切触れられていない気がしますが、気のせいでしょうか。これも、インパクトが大きいのに。

ハイパーバイザーは、vSphere 5.1 は順調に正当な進化を続けている印象、MicroSoft は Microsoft System Center 2012 Virtual Machine Manager が面白いと感じました。本に書いてある通りなら、簡単にプライベートを作れて管理できそうですが、実際に触ってみないと何とも言えないところ。Azure との連携がスムーズにできるようになると、シェアを伸ばしてきそうな感じはします。

クラウドにおいては、性能面でストレージが超重要になりそうですが、各社ストレージ製品がいろいろ賢い機能を持っているなと感じました。ストレージ階層化でよくアクセスするデータをSSDにおいたり、QoS 機能を持っているのがありがたい。SSDはますます重要になりそうですし、ここに高速な相変化メモリや磁気メモリが普及してくるとどうなるのかに注目しています。

私は、インフラへの興味を強く持っているので、全体を通して楽しく読めた一冊でした。

書籍レビュー『ITロードマップ〈2013年版〉情報通信技術は5年後こう変わる!』

このレビューは、2月頃に読んだものを、某SNS上に書いたものです。ただ、そのSNSは技術者中心の集まりでないので、そこで技術書のレビューを書くのはどうにも空気が読めてなかったように思います。やっぱり、適切な媒体はブログか、ブクログのようなサービスに書くのが妥当ですね。IT系の書籍に関しては、ブクログに書いたものにリンクして、このブログにも載せていきたいと思います。


ITをビジネスに活用していたり、IT業界に勤めている人がメインターゲットの一冊。
一年ごとに野村総合研究所から出されている本で、2013年版で8冊目だそうです。本書では注目される分野をピックアップして、それぞれの今後5年間のITロードマップ予想を示しており、ITに関する仕事をする人にとって、業界動向を探ったり、知見を得るために有用な一冊ではないかと思います。

以下、堅苦しい内容が多いですが、私が着目した部分、面白いと思った部分のメモです。

2011年版、2012年版は、クラウドとどう向き合うかインフラ寄りの話題が多かったです。一方、2013年版は「スマートフォンをはじめとしたスマートデバイス」「ビッグデータ」に注目した内容が多くなっています。

スマートデバイスに関しては、企業側としては顧客と接する新たなチャネルとなっていること、位置情報を利用したプッシュ情報の通知といった、今まで出来なかったことが色々と出来るようになってきて勢いのある分野です。他にも、保険会社が提供しているソフトがGPSや加速度センサーの情報を用いて安全運転だったかどうかの情報を残したり、医療機器の使用時間や回数といった情報をセンサーを通してスマホに送信し更にサーバに情報送信して患者の情報を管理したりといった、多種の分野で有用な事例が多いようで、こんなことにも活用できるんだと感心しました。

ビッグデータとは、要は今まで分析できなかったような巨大なデータのことです。最近は、サーバやストレージの性能が年々向上していたり、SSDのような高速に読み書きできるデバイスも普及してきました。また、Hadoopというソフトを用いることで多数のサーバを用いてビッグデータの解析をできるようになってきました。ただ、ビッグデータから有用な情報を引き出せるデータサイエンティストはまだまだ少ないのが実情です。データサイエンティストは、統計学の知識、Hadoopや統計解析用のソフト(RやSAS)などのソフトを使用する技術、ビジネス・業務への深い理解など、広く深い能力が求められるので、そう簡単になれるものではなく、市場価値はとても高そうな感じです。

また、本書では、技術面の話だけではなくプライバシーといったポリシー面の問題や、経験とセンスの良さといったコンピュータとはまた別の視点の話も紹介されています。
プライバシーについては、SNSスマートフォンの提供する様々な情報(位置やメールアドレス、その他色々)など、企業が得られる情報は色々ありますが、やはり個人情報の扱いに注意する必要があること。そのためには、蓄積する情報を必要最低限の項目に絞ったり、個人を特定できないようにあいまいな情報に加工したり、暗号化したりと色々考えないといけないようです。
勘とセンスのよさについてですが、「ダイナミック・ケース・マネジメント」として紹介しています。それによるとビッグデータで分かることもあるけれど、コンピュータによる解析だけでは分からないこともある。分析結果から勘・経験・センスをもって仮設をたて、それを検証する。これを短いサイクルでまわしていくことが勝ちパターンにつながっていくのだと書かれています。なので、コンサル的な視点、マーケティング部門のようなものの見方が欠かせないということになります。

こんな感じで、ITの分野は日進月歩で様々な進展があって目まぐるしいですね。個人的にはビッグデータが本当に楽しめそうな分野で、最近注目しています。

書籍レビュー『舟を編む』

舟を編む

舟を編む

技術ブログらしからぬ内容ですが、一般書籍を読んだ感想を。『舟を編む』。2012年、本屋大賞第一位の作品です。とある出版社の辞書編集部で、辞書を出版するまでのお話。個人的には、辞書発売までの、編集部内部でのプロセスを知ることが出来て面白い本でした。

辞書作りもある意味でものつくりなので、ソフトウェアの開発と共通する点もあると感じて興味深かったです。具体的には次のような点。

・標準化。辞書に統一感を持たせるための、執筆要領の作成
・学生アルバイト何十名を従えての人海戦術
・理解を一意にするための、表現の工夫
・バージョンアップ。辞書を改訂する場合は、時代とともに移ろい行く言葉に対応するために、内容を見直す必要がある。
・改訂時のデグレードチェック(ある言葉を採用しなくした場合に、参照先がないなどの不整合を除く作業)
・市町村合併などの、突発対応
・営業部、製紙会社などとの調整、交渉


タイトルは硬派なのですが、内容はなかなかライトでしたね。まじめくんのような、妥協せず一つのことにじっくり取り組む登場人物はとても好感が持てます。

平成25年春 -情報処理技術者試験プロジェクトマネージャを受けてきました

今日は、情報処理技術者試験のプロジェクトマネージャを受けてきました。

午前Ⅱは無事通過、午後Ⅰは結構不安、午後Ⅱはまず受からないだろうという出来でした。需要はなさそうですが、午後Ⅰの回答をさらしておきます。


○午後Ⅰ

問1

設問1
(1) クリティカルパスとなっているため
(2) グローバルに接続拠点がある安全なネットワークを利用できること
設問2
(1) a: 10, b: 9, c: 8
(2) 想定以上に機能のギャップがあり、設計期間が延びるリスク
設問3
(1) 来年1月初めから利用する要件だが、PJ完了が間に合わないため
(2) 顧客からの要求があった場合、サーバの管理レポートを提出できること
(3) 監査の受け入れが不可であるため

○問2

設問1
全社の業務プロセスの整理が十分でないにもかかわらず、各事業部との調整が不要との想定である点
設問2
(1) システム化により実現したいことは何であるか
(2) 同一の指標で比較評価できるように業務プロセスの整理
設問3
(1) 各事業部の担当者
(2) 各事業部の業務内容、業務システムで扱うデータ項目、更新タイミングを整理すること
(3)
要員の手配の観点: 要員計画よりも更に多くの要員が必要となるリスク
システムの品質の観点: 品質がW社に依存し、コントロールできないリスク
開発スケジュールの観点: 12月末までに予定の機能を正常動作できないリスク
------------------------------------
2013/6/21 この内容で73点でした。

au のメールサーバ 62 台ダウンの原因を推測してみる

4/16 に発生した au のメール障害の原因が、メールサーバ 62 台のダウンとの事。62 台ってすごいですね。

[auのiPhoneメール障害が復旧、原因はメールサーバー62台のダウン]
http://itpro.nikkeibp.co.jp/article/NEWS/20130416/471303/

こういうとき、部外者だと気楽なんですが、中の人は大変なんでしょうね。
せっかくなので、原因がどこにあるか根拠のない推測をしています。可能性としてありそうなものを挙げてみる。

単に処理をさばけなくなった

システムの想定する処理能力を超える処理要求が発生してサーバダウンにつながった。この場合、対策しないと再発しまくりそう。

パッチの副作用

パッチを適用することで、特定の処理が重くなった。

マシンダウンによる台数減少が引き起こす問題

障害でサービスにまわせる台数が減ると、1 台あたりにまかせる処理量も多くなってしまいます。このとき、安定稼動できる閾値を超えると、サーバダウンにつながりますが、さらに台数が減っての悪循環になってしまうので悲惨ですね。
仮想化で運用している場合、一台物理サーバが障害でダウンした場合、vMotion とかで一気に負荷が上がり更なる問題発生というのもありそうです。

ストレージの問題

複数のマシンから同じファイルを参照するなどの用途で、ストレージをマウントしていることはよくあります。ただし、ストレージに問題が発生した時、ノード側の対策が甘いとマウントしているサーバ側にも問題が発生したりします。例えば、定期的な処理で問題の領域へアクセスしている場合、作りが甘いと、処理実行のたびにプロセスがたまり続け、やがてサーバの負荷が高まりサーバダウンにつながったりとか。

スイッチの問題

実は単にスイッチの問題で、メールサーバにアクセスできなくなっただけ。ただ、この場合はサーバダウンという表現にはならないので、多分これはないです。

施設面

電源側の問題か、あるいは空調の冷却能力に問題が発生して、高温を検知してシャーシ側の機能で強制停止というのもありうる。

オペ担当者のオペミス

メンテ対象マシンだけのリブートのはずが、サービス中のマシンも対象に実施してしまったというのもありがちかも。これだけ台数が多いノードを似た用途で使っていると、ホスト名も似通っていたりするので、ミスも起こりやすくなります。

OS 側のバグ

208.5 日問題でリブートしたという説もわずかに考えられるかも。さすがにこれは無いと思いたいですが。


・追記

au の発表情報によると設備故障と書いてありますね。どの設備が故障したかは不明ですが。

[au携帯電話 iPhone iPad Eメールリアルタイム受信設定のお客様にてEメールがご利用いただけない状況について(完報:4月17日 03時30分現在)]
http://www.kddi.com/news/important/important_20130417032027.html

・追記(2013/4/25)
KDDI さんからの障害原因の報告が出ましたね。技術者向けの情報ですが、逆に分かりやすいです。62台の再起動は、現行設備への切り戻しを決定した後に切り戻しの手順として意図的に実施したのが真相のようですね。ただ、認証サーバの問題や、滞留したメールが引き起こす問題、流量調整がうまくいっていなかったことについては、挙げられませんでした。僕もまだまだだな。
http://www.kddi.com/corporate/news_release/2013/0425/pdf/besshi.pdf

シェルスクリプトでYYYYMMDD → YYYY/MM/DD

シェルスクリプトでYYYYMMDD → YYYY/MM/DD。簡単な内容ですが、即座に出来なかったのでメモとして残しておきます。

シェル変数

${var:n:m} でシェル変数 $var の n 番目から m 個の文字を取り出せるので、それを利用。

$ YYYYMMDD=20130418

$ echo ${YYYYMMDD:0:4}/${YYYYMMDD:4:2}/${YYYYMMDD:6:2}
2013/04/18
awk の substr
$ echo 20130418 | \
  awk '{print substr($1, 1, 4) "/" substr($1, 5, 2) "/" substr($1, 7, 2)}'
2013/04/18