新sanonosaシステム管理コラム集

LINE社に2000年の創業時から在籍。インフラエンジニア。このブログでは日々経験していることを記録するようにしています。

現在過去記事を少しづつ直しながら移行中です。(2016/5/28現在)
※旧blog: http://nosa.cocolog-nifty.com/
このエントリーをはてなブックマークに追加

「インフラエンジニアの教科書2 スキルアップに効く技術と知識」という本を書きました

このエントリーをはてなブックマークに追加

2016年8月26日に「インフラエンジニアの教科書2 スキルアップに効く技術と知識」という本が出版されますので、ご紹介させていただければと存じます。

自分が若かりし頃に、こういった内容の本があったら良かったのになあ、という内容を詰め込みました。この本に書かれている内容はどれも日常業務に必要なものばかりなんですが、ネットもくまなく検索してみても、未だにまとまって整理されているものをほとんど見かけないんですよねえ。。。



■章立て
CHAPTER-01 プロトコル
CHAPTER-02 OS
CHAPTER-03 ネットワーク
CHAPTER-04 データベース
CHAPTER-05 WEBのサーバサイド開発言語
CHAPTER-06 共通鍵暗号方式と公開鍵暗号方式
CHAPTER-07 障害対策と障害対応
CHAPTER-08 よく知られたセキュリティ攻撃
CHAPTER-09 インターネットの運用と発展をつかさどる組織や団体
CHAPTER-10 RFCの読み方と作られ方
CHAPTER-11 世界規模のインターネットサービス運営
CHAPTER-12 インフラエンジニアとして目指す方向


■アピールポイント 
・障害対応時に重要なOSの仕組みについて、ものすごく丁寧に書きました。OS上のプロセスがCPU、メモリ、ディスクなどのハードウェアとどのように連携しながら動作しているのかがわかるようになると思います。このあたりインフラ運用上すごく重要な基礎知識なんですが、最近はこういった内容が書かれた本をあまり見なくなりましたね。開発者の方にもこの章だけはインフラエンジニアだけでなくとも是非読んでいただきたいです。

・ネットワークに苦手意識を持っている人が多いので、最低限これだけ押さえておけば業務上困らないのではないか、という内容を書いてみました。

・データベースは、DBA視点ではなくてインフラエンジニア視点で書いてみました。ちょっと他の本とは書き方が違います。

・RFCの読み方を日本語で説明している本って意外とないので今回書いてみました。

・開発言語とWEBサーバ(Apache/Nginx/IISなど)の間をつなぐものについて、整理された情報があまりなくて今回整理してみました。この切り口で書かれた本は意外と他にない気がします。

・Javaの世界をインフラエンジニア視点で必要最小限に簡略化した上でわかりやすく説明しました。(開発者向けJava本だとインフラエンジニア視点で余分な情報がほとんどですから)

・SSL証明書の世界がどんどん変化していっていますが、昔勉強したきりで最新状況を押さえていない人も多いかとおもって、中間証明書、クロスルート証明書、EV証明書、ワイルドカード証明書などの内容を含めて書いてみました。

・インターネット関連組織であるISOC,IAB,IETFなどについても意外と日本では知られていないので今回書いてみました。

・WEB系企業に勤めるインフラエンジニアは概してWindowsに弱い人が多い(と思う)ので、普段あまり聞くことがないだろう内容(MFT、ファイル名文字コードの動的変化など)を書いてみました。

・世界規模のインターネットサービス運営に関わっている中で日々感じていることや実際に体験したことなどをまとめてみました。他であまり書かれない内容なので、面白く読んでいただけると思います。

■裏話
・前作「インフラエンジニアの教科書」が出版されるまで、インフラエンジニアというカテゴリーで出版された本がほとんどなかったと聞きます。結果的に前作がそれなりに多くの方に買っていただけたことで、結果的に各社からインフラエンジニアというカテゴリーの本が出されるようになった、らしいです。

・続編を書くことは全く考えてなかったですが、今回多くの読者の方や、各書店の店員さんからも名指しで続編の要望があったと聞きました。こういうことは珍しいらしく、結果的に引き受けることになりました。

・当初半年くらいで書き上げるつもりが、かなり丁寧に書いたために、1年近くかかりました。

・出版社のほうから「副題がないと売りにくいので副題つけてください」と言われて印刷所に入れるぎりぎりまで議論が続いてました。たしかに「インフラエンジニアの教科書2」だけだと前作との違いが購買を検討される方にとってもわかりづらいですよね。


■最後に
普段、新人インフラエンジニアを教育したり他部署から質問を受けたりしている中でいつも感じるのが、コンピュータの基本的な知識が不足しているので悩んでしまうのかな、ということです。そんな経験を踏まえつつ、他の本ではさらっと流されてしまう内容を丁寧に書いていたり、もしくは他の多くの本で書かれているような内容は省略したりとメリハリをつけながら、図を増やしたり文章を読みやすくしたりして極力理解してもらえるように丁寧に書きました。

これまで関わってきた本の中でもっとも愛着があり、また苦労した本でもあるので是非多くの方々に読んでいただければと思います。

どうぞよろしくお願いいたします。

インフラエンジニアの教科書2が入稿間近

このエントリーをはてなブックマークに追加
現在、次回作「インフラエンジニアの教科書2(仮称)」が入稿間近ということで、組版されたデータの最終チェックを行っています。

もうすぐ発売となります。多くの方々に役立てていただけるよう頑張りましたので、何とぞよろしくお願い致します!

ライブマイグレーションに失敗した話

このエントリーをはてなブックマークに追加
VMwareサーバの老朽化に伴って新しい物理サーバを用意して次々とライブマイグレーションしていたとき、1VMのみライブマイグレーションに失敗するという症状に見舞われました。

よくあるライブマイグレーションに失敗する事例としては、マイグレーション先のハードウェアリソース不足、異なったCPUを使っている、実は移行先のハードウェアが壊れていた等いろいろあると思いますが、今回の場合はちょっと違いました。

結論から言うと、このVM(仮想サーバ)のみ割り当てCPUコア数が1となっていたからでした。

ライブマイグレーション実行後しばらくは順調に行ってましたが、しばらくするとVMに一切アクセスができなくなる、いわゆるフリーズ状態となってしまいました。そこでもう一度vmstatを回しながらライブマイグレーションを行うと、「r」の列が高い数値を見せて、その後固まりました。「r」列というのは実行中プロセス数と実行待ちプロセス数の総和ですが、この数値が高いということはCPUリソースが足りていないことを意味します。これを手掛かりに原因がわかったのでした。

よい技術書の見つけ方

このエントリーをはてなブックマークに追加
「最近よい技術書って少ないんだよねぇ」という話しが話題に上がりました。そこで今回はよい技術書の見つけ方を考えてみました。 

【世間一般の良書と自分にとっての良書は一致しない】
まず重要なことなんですが、世間一般の良書と自分にとっての良書は一致しないです。読者の技術スキルや経験量がばらばらなので世間一般の良書は自身のレベルに合わない可能性が高いからです。技術的に正確で完璧であっても読者が読みこなせなければ意味がありません。

【買ってはいけない本は割とわかりやすい】
良い本というのは定義しにくいですが、悪い本というのは割と定義しやすいものです。例えば著者が技術をよくわかっていない本は買ってはいけないです。自分が知っていることを書いてある部分を読んでみて、正確でなさそうであれば買わない方が良いです。

本って数百ページも書くのは本当にしんどいです。その分量を全て正確な情報で埋め尽くすためには著者が技術の正確な理解と豊富な経験がないと不可能です。そんなわけで本の中身を見てみて少しでも雑な説明があったら著者の技術力は怪しいと思ったほうが良いかもしれません。

ただ、初心者向けの本はちょっと見極めが難しくて、著者は正確に理解していてあえて簡素に書いているのか、それとも著者が全然わかっていなくて結果的に簡素に書かれているのか。例えば「インターネットに接続するためには必ずデフォルトゲートウェイを設定しなければなりません」という説明を良しとしてよいのか、という話しです。 

【よい技術書をどうやって見つけるか】
というわけでいよいよ本題です。こういうのはテクニックというよりは目利きが必要で、ある程度の量の本を読んでいると見えてくるものではあるのですが(これは美味いビールの選び方をビールを飲んだことがない人に説明しようとするシーンに似てますね。麦芽100%、天然水、自家製ホップで作ったビールが必ずしも美味しいわけではない!)、あえて法則を書こうとすると非常に難しいですね。

百発百中ではないのですが、著者の経験則を交えながら書いてある本は割と当たりが多いと感じています。経験したことを書いているので文面に著者の気持ちがこもっています。一方著者が経験したことがないことを本を書くために無理やり調べながら書いているような本だと気持ちを全然感じません。

この考え方で行くと、例えばOSの本だったら著者のプロフィールを見て、この人はOSが大好きなのかそうでないのか知るだけでも少なくとも良い本か悪い本か判断できるような気がします。

購買の時間を少しでも短縮するために

このエントリーをはてなブックマークに追加
サービスの成長に伴い購買額が大きくなるにつれて商談の頻度が増えてきます。例えば数千万円クラスの機器を買おうとすると、複数のベンダーから平均10回くらい来訪いただくので、同時期に複数のものを買おうとすると購買専任の人がいないと毎日が商談になってしまいます。そんな中、少しでも商談の時間を短縮するためにいろいろ工夫したのでご紹介してみます。

【1.前もってお茶の準備をしておく】
お客様にお茶を出すのは常識ですが、自社からの参加者が自分ひとりだけだとお茶を準備するだけでも大変です。この問題に対して私はこのようにするようにしています。  

1. 前もって来訪者の人数を聞いておく。

2. 来訪5分前に人数分のお茶を入れて部屋に置いておく。
3. 部屋に入っていただいたら直ちにお茶を配る。

これだけで5分~10分は短縮できます。

【2.会議室の予約を短めにする】
商談を1時間刻みで行うことが多いですが、本当に重要な部分はそのうちの半分に満たないことが多いので、私はこのようにしています。

1. わざと会議室の予約を短めにする。(45分とか)
2. 来訪者に対して、この会議室は45分しか使えないと前もって宣言する。

これで15分の短縮です。

【3.要件定義資料を作り込んでおく】
商談の場ではこちらの要件について非常に長い時間ヒアリングを受けるのが普通です。これは思ったより時間がかかるので、私はこのようにしています。

①初回のコンタクト前にやりたいことを箇条書きしてメールで送っておく。

②最初の商談でこちらが疑問に思っているポイントだけを確認し、要件定義を作る。

こうすると2回目の商談から具体的な要件定義資料を元に話しが進むのでかなり商談が早く進みます。これで3時間以上の短縮になるのではないでしょうか。

【4.最終決定日を明確に伝える】
いつ最終的に決めますということを明らかにしておくと、そのタイミングで最終見積もりが出てきます。業者から見て最終決定日がわからないといつまでもバッファを持たせるのでいつまでも商談が終わりません。

【5.最終価格決定方法を業者に選んでもらう】
最終価格決定方法として以下の2つの方法があるかと思います。私はこのどちらがよいか業者に選んで決めてもらっています。

1.相見積もりを取っている業者の情報をお互いの業者に流しながら、どちらかがギブアップするまで見積もり書を交換する。
 →確実に安くなりますが、時間はかかるし決定した業者の利益がほとんどない状態になるので今後のお付き合いを考えると本当はあまりいい方法ではないです。

2.一発勝負で決める。
 →お互い後腐れがないし時間もかからないので個人的にはこちらのほうが好きです。

LAN内にループがあるとどうなるか

このエントリーをはてなブックマークに追加
LAN内にループがあってはいけないというのは常識中の常識ですが、専門スタッフが担当するデータセンターならいざしらず、社内ネットワークにおいてはいろいろな社員がいるのでそんな常識が遵守される保証はありません。

以前社内ネットワークが異常に重くなるというトラブルが発生し、調べたら会議室のHUBが見事にループとなっていました。そのときのMRTGが運よく残っていたので公開してみます。こういう波形が出たらループを疑ってみてください。

 L2loop

(2016/7/14 追記: 2005年に書いた記事なので内容が古いです。現代はループ防止機能付きのスイッチなど様々なループ防止ソリューションがあるので昔ほどループを見かけなくなりました)

「インフラエンジニアの教科書」という本を書きました

このエントリーをはてなブックマークに追加
2013年11月に「インフラエンジニアの教科書」という本を出版させていただきました。おかげさまで大変ご好評いただき、2016年6月現在でも多くの本屋さんで平積みいただいております。

書評してくださった方がいらっしゃるのでリンクさせていただきます。どうもありがとうございます。^^
・『インフラエンジニアの教科書』この本をなんと呼ぶ?教科書と呼ぶ!
・インフラエンジニアの教科書"を読んで
・若手インフラSEに好評だったお勉強の本4冊
・#e100q 新人エンジニアにお勧めする一冊
・[書評] インフラエンジニアの教科書
・まさに教科書「インフラエンジニアの教科書」
・インフラエンジニアの教科書
・【読書記録】インフラエンジニアの教科書
・「インフラエンジニアの教科書」を読みました。
・[読書] インフラエンジニアの教科書
・インフラエンジニアの教科書いいね
・ブクログ インフラエンジニアの教科書
・インフラエンジニアの教科書
・インフラエンジニアの教科書
・インフラエンジニア・書籍学習まとめ
・佐野裕「インフラエンジニアの教科書」は、入門書
・元ネットワークエンジニアのサーバ寄り技術書入門としてオススメ♪
・ヘテムルの本棚~インフラエンジニア編~
・インフラエンジニアが知っておくべき基本のこと
・新人エンジニアにお勧めする一冊 ~Trifort サーバサイド&インフラ篇~
・新人インフラエンジニアにゴールデンウィーク中に読んで欲しい20冊
・インフラ初心者におすすめの書籍
・WEBエンジニア志望がやった方が良さげな勉強
・Webエンジニアへ送るインフラのおすすめ本:記事7本
・非エンジニアがエンジニアチームに入る前に読んでおきたい本のまとめ
・最近おもしろかった本を5冊選んでみた

他にもたくさんご紹介いただいているみたいなんですが、抜き出しきれませんでした。すみません。。。

会社の人事blogにも掲載いただきました。
・【書籍情報】インフラエンジニアの教科書、発売中です


執筆時にこだわった点をアピールしてみます。

・「技術書なのに読みやすい」という路線を目指しました。さくさく読めると思います。

・文書だけだと読むのに疲れるので可能な限り図を入れました。

・起業してから現在に至るまで、個人的に悩んできたことの多くを盛り込みました。特に新たにインフラを立ち上げる場合役に立つと思います。例えば何か買いたいときどのようにベンダーや営業さんと付き合えばよいか、ルータはどれを買えばよいか、データセンターのラックにどこに何を設置すれば良いか等々、他の本ではあまり書かれていないような具体的なレベルのことがたくさん書いてあります。

・メモリには「ランク」という概念がありますが、拙著ではこのランクの意味をわかりやすく正確に説明している国内唯一の本ではないかと自負しています。ネットでくまなく探しましたが、日本語、英語共わかりやすく説明しているサイトが見つからなかったのでした。

・中小オープンソース系企業であまり使われないものについて一通り把握するのに便利です。
  ・Windowsライセンス体系
  ・VMwareライセンス体系
  ・ストレージの種類や技術全般
  ・エンタープライズ機器(電話回線接続してベンダーが障害検知する話しとか)
  ・SASディスク、FCディスク、Fusion-IO(ioDrive)の写真
  ・光ファイバ系の写真(ケーブル、LCコネクタ、SCコネクタ、GBIC、SFP)
  ・ネットワークファブリック構造
  ・データセンターの空調方式(排熱吸引方式、外気空調方式など)
など一通り網羅しています。

・一方、普通の用途に使われないと思うものはばっさり切り捨ててあります。例えばVMwareの製品体系は複雑ですが、本書ではvSphereとvCenterにしか触れてません。

・ライセンス購買のリファレンス的に使えるようにもしました。Win, RHEL, SQLSVR, Oracle, VMwareなどのライセンス体系と価格をわざわざ書いているのは、購買検討時にいちいちネットで検索しなくても済むので便利だからなのでした。ネットとは違い更新が効かない一般書で製品価格を入れるのはリスキーなので普通の本ではあまりやらないと思います。

では~。

英語ができると技術習得が異様に速いと思った件

このエントリーをはてなブックマークに追加
私の所属しているチームに新しい外国人メンバーが加わりました。彼は小学生の頃から英語で授業を受けてきただけあって英語はネイティブレベルです。ついでに書くと日本生活も長いので日本語もネイティブレベルです。

とはいえインフラエンジニアとしてのレベルはまだ発展途上なのでいろいろ教えながら業務にあたってもらっていますが、驚いたのは新しい技術の学び方です。

Hyper-V環境からVMware環境への移行

このエントリーをはてなブックマークに追加
Hyper-V環境とVMware環境が混在していて、今後VMware環境に統合しようと、せっせとHyper-V上のゲストOSを(サーバオーナーと交渉して)撤去していました。しかしふと思いつきました。「ひょっとしてHyper-VのゲストOSイメージをVMwareのゲストOSイメージに変換するツールがあるのでは?」と。ということで探してみたら「Vmware vCenter Converter Standalone」というツールがあっさりと見つかりました。

ということで今回はHyper-V環境からVMware環境への移行したときのことを書いてみます。

【移行手順】
1. 「Vmware vCenter Converter Standalone」(無料)をダウンロードしてきてインストールして起動します。すると非常にシンプルな画面が現れますので、「Convert machine」をクリックします。

1

2. Hyper-Vの管理ツールであるSCVMM(System Center Virtual Machine Manager)のログイン情報を入力します。

3. 移行するゲストOSを選択します。

4. 移行先であるvCenterもしくはVMwareサーバのログイン情報を入力します。

5. 移行先のクラスタやハイパーバイザーを選択します。

6. オプションを設定します。ここで特に注意すべきは、「Data to copy」でThick->Thin provisioningにすることと、NICのVLAN情報を正しいものに変更しておくことです。
2


【やってみて気づいたこと】

データセンター移転を検討するということ

このエントリーをはてなブックマークに追加
iDC(データセンター)移転はものすごく大変です。特にサービスを稼動させながら移転させるなんてことは、普通に考えただけでもかなりしんどい作業です。そんなiDC移転を数回経験した経験から、それでもiDC移転を検討することの重要性を今回は述べてみたいと思います。

【iDC移転はどんなとき検討されるか】
いろいろあります。単純に思いつく限りだと、
  • iDCのキャパシティが小さくサーバ増強に限界が見えた
  • 費用対効果を計算し、移転費用を考えても他者に乗り換えたほうが安い
  • セキュリティや耐障害性向上を考えたとき利用中のiDCだと限界がある
  • 会社合併によりiDCも統合の決定が下った
などでしょうか。

【なぜiDC移転を検討することが重要なのか】
今利用し続けているiDCにたとえ満足していたとしても常にiDC移転を検討することは重要です。それはiDC間で競争が起こっているからです。いろいろなiDCをずっと見てきていますが、iDCの機能やサービスの進化や価格下落は想像以上のものがあります。iDC移転を検討しないということは、最初に契約した条件でそのまま契約続くことに他なりません。外を見渡せば、
livedoor プロフィール
著書




RSS Feed