cloretsblackのテクニカルノート

言葉の意味はよくわからんがとにかくすごい自信だ

エンジニアの報連相について

先日、後輩君と一緒に会議に出まして、 そこで後輩君の報告を聞きながらちょっと思ったので書いてみることにします。

まあ、後輩君が要領を得ない説明をするというのは、非常にありがちで自分もそうだったなーと思い出しました。
恥をさらすようですが、昔自分がやっていたことと、今気を付けていることを整理してみたいと思います。

昔の自分

上司「黒ブラくん、進捗はどうですか?」
ぼく「えっと、いまプログラムを書いていて、コンパイルエラーがやっとなくなりました」
上司「コンパイルエラーが無くなるのは当り前でしょ」
ぼく「あっはい」
上司「どうなの?」
ぼく「これから流してみます」
上司「間に合いそうなの?」
ぼく「大丈夫だと思います」

今思うと、だいぶアチャーな感じですね。。
このようなやり取りをしていたのは、ぼくが商社の情報システム部門で入社2年目くらいのころでした。
非コンピュータ系の学部を卒業した状態で、1年目はPCヘルプデスクをやり、2年目の後半からは基幹システムの新規開発プロジェクトに参加し、プログラム製造を担当していました。
初めてのプログラミングはPLSQLで、SQLの文法を理解するところからでしたが、商社の新人として入社したので、情報処理の教育はほぼ受けていません。
SQLを覚えて」と言われて本を渡される感じの現場です。
当時、基本情報処理試験には3回落ちており、受験自体をやめてしまったので、基礎はだいぶ抜けていたと思います。 (今ではさすがに受かると思いますが。。)
なので、非常に聞いていて不安を感じる報告ですね。これからの工程とか理解してんのかという感じです。
もちろん当時は理解せずに報告しており、後で大変な目に合うのですが。。

どうすれば良かったか?

  1. その場にいる人のレベルや会議の趣旨を理解した上で質問の意図と求められるレベルを想定する

  2. 想定するレベルに合わせて報連相する

  3. 具体的に進捗確認であれば、現在の状態、今後の予定、スケジュールとの差異、問題が発生しているか、等を簡潔に述べる

  4. 必要であれば、ホワイトボードに図を書く(積極的に)

報連相の常として結論から先に言うというのも大事だと思います。 あと、上司から質問が何回も出るというのは「こいつ本当にわかっているのか?」という疑問を払しょくするためでもあります。
そこで4に挙げたように、図を描くと「わかっている感」が生まれるので、聞いているほうに安心感が出てきます。 会議の時間を使ってしまうという問題はあるのですが、積極的に使っていきたいテクニックです。

製造工程の理解とマイルストーンの設置、スケジュールの感覚などは基礎的な教育と経験で得られるものなのですが、進捗の報告をする前に理解しておかないとそもそも話が通じないので、そこは上司や先輩とかがフォローしてほしいですね。

ちなみに後輩君はぼくと比べて基礎が非常にしっかりしており、「おまえこの年齢でこのスキルって、無敵じゃね?」ってぐらいの逸材なので、この手のテクニックを積極的に伝授してパーフェクト超人にパワーアップしてもらおうと思っています。

f:id:cloretsblack:20161217053931j:plain
だいぶ待っていたよ  

集英社 ジャンプコミックス ゆでたまごキン肉マンより引用

ハンズオン体験記

試してわかるSDN ~Tremaではじめるパケット生成ハンズオン~ で講師を務めました。

www.slideshare.net

ハンズオンは難しい

私にとっても初めてのハンズオンだったので、様々な学びがありました。
参加者のレベルやペースも様々ですし、フォローが難しいです。 Tech-Circleの皆様のご協力で何とか形にできた感じです。 本当にありがとうございました。

参加者の環境がマチマチ

やはりプラットフォームの差異を甘く見てはいけないですね。 当初VMでやれば大丈夫だろうと思っていましたが、インポート時にネットワーク周りで予想しなかった挙動があり、一瞬戸惑いました。
Windows10での予行演習はしていたのですが、私の環境とは違う動作をしていたことと、ハンズオン中に出てくるとアナウンスが難しいというのは貴重な経験でした。

お一人、Windows7の32bit環境でおそらく64bitのVMを動かすのが初めてという方がいて、インポートのエラーで躓き、実質放置状態になってしまいました。
BIOSのVT-x拡張を調整してみてもらえますかと言ったのですが、ハンズオンに来てBIOSの設定変えるの嫌ですよね。。
予め案内等に書いておけばよかったです。ごめんなさい。

それ以外は比較的スムーズに進捗しましたので、至らない点は少々あったものの、 VMで環境をまとめておいたのは良いアイデアだったと思います。

ちなみに資料中、後半のCMが長いのは尺の関係です。。

このハンズオンをご自宅ででもやってみたいという方がいらっしゃれば、 VMをご提供いたしますのでtwitterまでお知らせください。

パケットレコーダー「Sonarman」をRaspberryPi 3に移植してみました

「Sonarman」とは?

機械学習による警告機能」と「遠隔での高い操作性」が特徴のパケットキャプチャ装置です。 一定期間のパケットを保存しておくことにより、ネットワークのトラブルシューティングを強力に支援します。

システム障害の原因が分からないなどの理由で「再現待ち」ステータスで障害票が積み残ることがありますが、そんな負の遺産を一掃するために開発された製品です。

f:id:cloretsblack:20160930092841p:plain
システム管理者の切実な願い

f:id:cloretsblack:20160930092846p:plain 圧倒的感謝
小学館コロコロコミックス『ドラえもん のび太ドラビアンナイト』より引用

「Sonarman」について詳しくはこちらをご参照ください。

develup-japan.co.jp

今回の挑戦

x64アーキテクチャからARMへの移植作業として、Cで書いたDPIプログラムのクロスコンパイルと細かいバージョンが異なるパッケージ間の調整作業がメインでした。少々戸惑うこともありましたが、現時点で確認できている範囲では概ね問題なく動作しています。
以下に作業を通して感じたこと、考えたことなどを、書き留めておこうと思います。

f:id:cloretsblack:20160930222105j:plain

メリット

HWの調達コストが劇的に下がった

広く流通しているシングルボードコンピュータであるRaspberryPiの採用でHWの入手性が大きく向上しました。 また、原価も大幅に下げられたので、拠点等、複数の計測箇所に安価に設置することが可能になります。 営業的な視点で言うと、原価が広く知られているというのは良いことなのか?という気は非常にしていますが。。

コアが増えた

既存の2コア->4コアになりました。 ただし、メニーコアのメリットを十分享受できる構造のアプリケーションではないため、コア増による速度向上はあまりありません。 動作の安定性には寄与していると思います。

発熱が減った

さすがの低消費電力。発熱は劇的に少なくなりました。これは大きなメリットです。

GPIOによる応用の余地が広がった

不正なパケットによる緊急事態に音を鳴らしたりLEDを光らせるなどのアクションを取らせることができます。 たとえば「IPアドレスの重複を検知して光る箱」を作ることができます。 何の意味があるかはさておき、面白い使い方を考えてみようと思います。

小型化

大分小さくなり、非常に満足しています。 現行機種の約4分1のサイズです。

省スペース電源

USB電源になりますので、省スペースになりました。スイッチやサーバから給電するようなことも可能になるかもしれません。

その他

現行機種の「Sonarman」はシリアルで設定するのですが、シリアルケーブルを持っていないというお客さんも普通にいらっしゃいますので、「HDMIを挿せば普通のPC」というのは、かなりユーザーフレンドリーです。(RaspberryPiもシリアル接続できます)

デメリット

性能

あまり速くないです。50Mバイトのパケットキャプチャを読んで、機械学習など諸々の処理を行うのに300秒ほどかかるケースがちらほら。キャプチャの内容によって処理速度が異なってくるのであまり単純な比較はできませんが速くはないです。 したがって警告などのリアルタイム性はそれなりです。 実運用での経験から言えば上記の制約はそれほど重要ではないですが。

Ethernetポート数

3ポートから1ポートに減りました。 唯一のRJ45ポートはキャプチャ用にせざるをえませんので、操作用のインタフェースはWiFiになります。 どうしても必要なときにはUSBで増設することも可能です。 実際の設置で発生していた、UTPケーブルを挿し間違えてキャプチャが取れなかったという悲しい事故は減るはずです。

容量

キャプチャを格納するDISKの容量は増設に頼ることになります。 128GのUSB小型フラッシュメモリをマウントして使います。 アマゾンで3000円くらいなので非常に安価ですが、 USBが2.0ということもあり、速度としてはそれなりかと。

感想

全体として、かなり満足感があります。 正直、もうこれでいいじゃん的な何かです。 価格も含めて良く知られているプラットフォームであるということもあり、 購入/評価の敷居が下がることを期待しています。 開発用途には非常に便利ではないかと思います。

IoTというキーワードは、今まであまり意識していなかったのですが、 安価なレコーダーを潤沢に設置することで、「数で押す」という戦い方が出来るような気がしています。 結果として障害に関するトレーサビリティが劇的に向上するため、 システム管理者にとっては嬉しいことではないかと思います。

「ピンチに頼れる飛び道具」として小型化と大幅なコスト削減を実現した、新型「Sonarman」にご期待ください!

JTF2016に参加しました。

今回のJTFは「IoTxAIxインフラ時代の最新技術、やってみたSP - 俺の屍を越えて行け -」というテーマだったので、 DevOps、人工知能機械学習等の分野に付随するインフラに関するセッションが多く、実際にやってみてどうだったかという、非常に興味深いプログラムが目白押しでした。

そんな中、発表者として登壇させていただいた中で考えたことなどを書きとめておきたいと思います。

何をやったのか

海外のネットワーク運用という比較的珍しい状況の中で編み出したパケットキャプチャ術と解析技術の紹介をしました。 以前発表した内容に加え、失敗と試行錯誤の中で生まれたダッシュボードの機能とユーザーの追跡機能にフォーカスして、その改善プロセスと考えた事を発表してみました。

www.slideshare.net

結果どうだったか

多くの方から勉強になったとの声を頂きました。 情シスという立場でこのような発表をする人は多分変わり者なので、珍しさも手伝って少し過大評価されているところもあると思います。
当日Sonarmanの開発者ライセンスをお配りしたこともあり、ご来場いただいた方に、単なる主張/情報だけでなく明日から役立つ何かを提供できたのではないかと勝手に思っています。

自分自身の感想

今回参加させていただいた事は自分自身にとって、非常に楽しく勉強になりました。 運営の方々には大変お世話になりました。 このようなイベントを用意することはものすごく大変な事だと思います。(準備に半年かかったそうです。。) この場を借りて心より御礼申し上げます。

一方で当日の発表や懇親会などで色々な方のお話を伺い、エンジニアとしてだけではなく、経営者の立場で考えたときに、周囲の方がまぶしく思え少々へこんでしまった所があります。 会場にいらっしゃった社長さんは皆さんすごい人ばかりで、やっている事も全然違うので、参考にするのは大分難しいな、というのが正直な所です。
しかし上を見ればキリがありません。 そもそもJTFを運営/スポンサードされるような経営者と自らを同じカテゴリーに入れることが大きな間違いと言えます。
自分は自分なりに必要とされる場所で必要とされる仕事を粛々とやるしかないのだということが一つの学びでした。

余談ですが、ある来場者から弊社の経営に関する「やっちゃったスペシャル」を聞きたいという要望を頂きました。。
まだ全然経営がしっかりしていないのにそんな話をするのは百年早いので、地道に一つずつ積み上げていこうかと思います。

TremaDay#9に参加しました

中国のインターネット規制とOpenflow networkについてTremaDay#9で発表してきました。

TremaDayとはオープンソースのOpenflowフレームワークであるTremaを中心としたネットワーク関連のオモシロ発表会です。

発表資料

www.slideshare.net

これが許される雰囲気といえばTremaDayの空気感はおわかりいただけると思います。

今回のブログのテーマは2つ、

  1. TremaDayという素晴らしいコミュニティ

  2. 発表をしていて思ったこと

です。

  1. TremaDayはいいぞ

一言で言うと大分自由です。 発表する方々のレベルがかなり高いのは、Trema自体が誰でも使えるソフトウェアではないということもあり、必然的に高いレベルの人しか興味を示さないこともあると思います(少なくとも今のところは)

自ら手を動かす人たちと面白いことを考えるのは最高です。 ちなみに上記のツイートの方は携帯電話端末にOpenvSwitchを入れて次世代データセンターを手のひらに収めるという、なんだろう、野心的すぎる発表をしてくださいました。控え目に申し上げて常人ではありません。

2.発表をしていて思ったこと

他の人たちの発表を見ていて、自分との違いや己のレベルについては常に意識するのですが、私の今いる場所(情シス担当者)の特徴として、エンドユーザーと直にやり取りが出来、試したことのフィードバックを非常に得やすいポジションであることが挙げられます。 Software Definedなネットワークやそれに付随するシステムを開発するにあたり、これは思ったよりも大きなメリットではないかと思います。

IDEやソース管理、DevOpsなどの各種ツールにより開発が効率化し、高速化している昨今、このようにPDCAを高速に回してソフトウェアを作りこむプロセスはなかなか充実しており、改めて現場に近いことのメリットを感じています。 今後とも、色々考えて楽しく手を動かしていこうと思います。

最後に 皆もTremaDayに行こう!

NPStudy#8で発表しました(追記)

前のエントリで発表について書いていたのですが、 思ったよりも反応を頂いておりまして、 その中で鋭いご指摘があったので追記したいと思います。

今回発表した機能には、「フィルタ」と呼んでいるモジュールがありまして、これは私が10年以上に及ぶ国内外でのトラブルシューティング経験と採り溜めた数百ケースのパケットキャプチャを分析した結果を元に、マニュアルで実装されているものです。

機械学習というと、このようなフィルタをコンピュータが賢く自動生成するようなイメージがあり、結局手で書いてるのか、という意味で少し期待はずれだったのではないかと思います。スミマセン。。(ご指摘有難うございます!)

ただ、このフィルタを自動生成するのはパケットというデータの構造と性質上、技術的に難しい気がしています。(もし「出来るよ」という方がいれば是非教えていただきたい部分です。)

結局、どこに機械学習的な要素を入れたのかというと、フィルタを通して検出された値が、警告に値するか否かの判断基準の部分です。 外れ値としてのボーダーラインを、設置環境における過去データから導かれる平均値との距離で判断しているという考え方になります。計算コストや実装難易度、説明のしやすさなども考慮して採用しました。

ネットワーク障害対応の常として、問題の検出だけでなく、人間によるパケットキャプチャの検証作業を平行して行うため、機械学習アルゴリズムはその判断過程を検証できるものを選択する必要があると思っています。 そのため、決定木のようなものを検討中ですが、まだまとまっておらず未実装です。。

この機能についてはまだまだ発展させていけると思っていますので、手元にある豊富な実データを元に、様々に分析してみたいと思っています。

NPStudy#8で発表しました

ネットワークプログラマビリティ勉強会#8で発表させていただきました。

www.slideshare.net

テーマが分散して、まとまりのない発表になってしまった感あり、反省です。 技術的には泥臭くフィルタを書いたりしていてスマートとは言い難いですが、実運用上の細かい話がネタとして多少受けていたようです。。

参加者はみなさんネットワークのエキスパートぞろいで、小さなユーザー企業ではリーチ不能な人たちばかりです。 久しぶりにネットワークの濃い話をたっぷりできたので、非常に癒されました。 情シス担当者は周りに技術に対する理解者が少ないという意味で、とても孤独な一面があります。 このようなコミュニティに参加することができて、とても幸せです。

今、世の中では盛んに情シスへのdisが言われています。 いわく、デジタルビジネスに対応できていないとか、 基幹システムのお守りが精いっぱいとか、技術力が低いとか。

確かにうなづける部分もあり、どうすればいいのか、私なりにいつも考えています。 その中で私は経営まで含めたオールラウンダーとしてのキャリアを目指そうと考えており、 そのためにプロダクトの製作や販売に取り組んでいます。

外野は色々な事を言いますが、日々ユーザーと向かい合っているのは情シス部門のスタッフなわけで、全体最適、コスト配分を考えながら高品質なサポートとチェック機能を提供し続けるというミッションを遂行しなければなりません。 自分でも「分不相応に意識高いなー」と思わなくもないですが、思考停止が一番良くないことだと思うので、少しずつでも考え、手を動かし、発信していこうと思います。