RFC8365 Ethernet VPN(EVPN)を使用したネットワーク仮想化オーバーレイのソリューション

BGP EVPN Networking VXLAN NVGRE RFC翻訳

はじめに

この文書は RFC8365 A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN) の日本語訳です。

翻訳者はデータセンターネットワークの専門家ですが翻訳の専門家ではありません。技術的な意味を維持した上でなるべく読みやすい日本語になるようにしているため、英文の直訳ではなく一部のニュアンスが欠けた文章になっている場合がありますのでご了承ください。オリジナルの目次、謝辞、参考文献等は省略しています。

免責

いつものやつ

目次

  • はじめに
    • 免責
  • 目次
  • Abstract
  • 1. はじめに
  • 2. Requirements Notation and Conventions
  • 3. 用語
  • 4. EVPNの特徴
  • 5. EVPNオーバーレイのためのカプセル化方式
    • 5.1. VXLAN/NVGREカプセル化
      • 5.1.1. 仮想識別子のスコープ
      • 5.1.2. 仮想識別子のEVIへのマッピング
        • 5.1.2.1. RTの自動計算
      • 5.1.3. EVPN BGP経路の構築
    • 5.2. MPLS over GRE
  • 6. 複数のデータプレーンカプセル化のEVPN
  • 7. シングルホームNVE - ハイパーバイザに存在するNVE
  • 8. マルチホームNVE - ToRスイッチに存在するNVE
    • 8.1. EVPNマルチホーミングの特徴
      • 8.1.1. マルチホームしているESの自動発見
      • 8.1.2. 高速収束とMass Withdrawal
      • 8.1.3. スプリットホライズン
      • 8.1.4. エイリアシングとバックアップパス
      • 8.1.5. DF選出
    • 8.2. EVPN BGP経路と属性に対する影響
    • 8.3. EVPN手順に対する影響
  • 9. マルチキャストのサポート
  • 10. データセンター相互接続(DCI)
    • 10.1. GWを使用したDCI
    • 10.2. ASBRを使用したDCI
      • 10.2.1. シングルホームNVEとASBR機能
      • 10.2.2. マルチホームNVEとASBR機能
  • 11. セキュリティについての考察
  • 12. IANAについての考察
  • 13. 参考文献
続きを読む

RFC7432 BGP MPLS-Based Ethernet VPN

BGP EVPN Networking RFC翻訳

はじめに

この文書は RFC7432 BGP MPLS-Based Ethernet VPN の日本語訳です。

翻訳者はデータセンターネットワークの専門家ですが翻訳の専門家ではありません。技術的な意味を維持した上でなるべく読みやすい日本語になるようにしているため、英文の直訳ではなく一部のニュアンスがかけている場合がありますのでご了承ください。オリジナルの目次、謝辞、参考文献等は省略しています。

免責

いつものやつ

目次

  • はじめに
    • 免責
  • 目次
  • Abstract
  • 1. はじめに
  • 2. 要件の仕様
  • 3. 用語
  • 4. BPG MPLSベースのEVPNの概要
  • 5. イーサネットセグメント
  • 6. イーサネットタグID
  • 7. BGP EVPN経路
    • 7.1. Ethernet Auto-discovery経路
    • 7.2. MAC/IP Advertisement経路
    • 7.3. Inclusive Multicast Ethernet Tag経路
    • 7.4. Ethernet Segment経路
    • 7.5. ESIラベル拡張コミュニティ
    • 7.6. ES-Import Route Target
    • 7.7. MACモビリティ拡張コミュニティ
    • 7.8. デフォルトゲートウェイ拡張コミュニティ
    • 7.9. MAC-VRFごとのRoute Distinguisherの割当方法
    • 7.10. Route Targets
  • 8. マルチホーミング機能
    • 8.1. マルチホームされたイーサネットセグメントの自動発見
    • 8.2. 高速収束
      • 8.2.1. Etherenet A-D per ES経路の構築方法
        • 8.2.1.1. Ethernet A-D経路のターゲット
    • 8.3. スプリットホライズン
      • 8.3.1. ESIラベルの割り当て
        • 8.3.1.1. Ingress Replication
        • 8.3.1.2. P2MP MPLS LSP
    • 8.4. エイリアシングとバックアップパス
      • 8.4.1. Ethernet A-D per EVPN Instance 経路の構築
    • 8.5. Designated Forwarder選出
    • 8.6. シングルホームのPEとの相互運用性
  • 9. ユニキャストMACアドレスへの到達性の決定
    • 9.1. ローカル学習
    • 9.2. リモート学習
      • 9.2.1. MAC/IP Address Advertisementの構築
      • 9.2.2. 経路解決
  • 10. ARP and ND
  • 11. 複数宛先トラフィックの処理
  • 12. Unknownユニキャストパケットの処理
    • 12.1. Ingress Replication
    • 12.2. P2MP MPLS LSP
  • 13. ユニキャストパケットの転送
    • 13.1. CEから受信したパケットの転送
    • 13.2. リモートPEから受信したパケットの転送
      • 13.2.1. unknownユニキャストの転送
      • 13.2.2. knownユニキャストの転送
  • 14. ユニキャストパケットのロードバランス
    • 14.1. PEからリモートCEへのトラフィックのロードバランス
      • 14.1.1. Single-Active冗長モード
      • 14.1.2. All-Active冗長モード
    • 14.2. PEとローカルCEの間でのトラフィックのロードバランス
      • 14.2.1. データプレーン学習
      • 14.2.2. コントロールプレーン学習
  • 15. MACモビリティ
  • 16. マルチキャストとブロードキャスト
  • 17. 収束
    • 17.1. PE間のトランジットリンクとノードの障害
    • 17.2. PE障害
    • 17.3. PEとCEの間のネットワーク障害
  • 18. フレームの順序制御
  • 19. セキュリティの懸念事項
  • 20. IANAの懸念事項
続きを読む

RFC7938 - 大規模データセンター内でのルーティングのためのBGPの利用方法

BGP Networking RFC翻訳 Datacenter

はじめに

この文書は RFC7938 - Use of BGP for Routing in Large-Scale Data Centers の日本語訳です。

翻訳者はデータセンターネットワークの専門家ですが翻訳の専門家ではありません。技術的な意味を維持した上でなるべく読みやすい日本語になるようにしているため、英文の直訳ではなく一部のニュアンスがかけている場合がありますのでご了承ください。オリジナルの目次、謝辞、参考文献等は省略しています。

免責

いつものやつ

目次

  • はじめに
    • 免責
  • 目次
  • 概要
  • 1. 導入
  • 2. ネットワーク設計の要件
  • 3. データセンタートポロジーの概要
  • 4. データセンタールーティングの概要
    • 4.1 L2オンリー設計
    • 4.2 L2/L3ハイブリッドの設計
    • 4.3 L3オンリー設計
  • 5. ルーティングプロトコル設計
  • 6. ECMPの考察
    • 6.1 基本的なECMP
    • 6.2 複数のAS番号をまたがるBGP ECMP
    • 6.3 重み付けされたECMP
    • 6.4 コンシステントハッシュ法
  • 7. ルーティング収束の特性
    • 7.1 障害検知のタイミング
    • 7.2 イベント伝搬のタイミング
    • 7.3 Closトポロジーのファンアウトの効果
    • 7.4 罹障範囲
    • 7.5 ルーティングマイクロループ
  • 8. 設計の追加の選択肢
    • 8.1 サードパーティ・ルート・インジェクション
    • 8.2 Closトポロジー内の経路集約
      • 8.2.1 Tier 1機器レイヤーの集約
      • 8.2.2 単純な仮想アグリゲーション
    • 8.3 ICMP Unreachableメッセージのマスカレード
  • 9. セキュリティの懸念事項
続きを読む

Intel NICを搭載したLinuxサーバのLLDPが正しく動作しない問題

サマリー

Intel NICを搭載したLinuxサーバにおいて lldpd をインストールして設定を行ってもその設定が反映されず、ハードウェアの情報が表示される場合、Intel NIC (i40e) のLLDPオフロードが有効になっているためこれを無効にする必要がある。

詳細

lldpdを apt install lldpd でインストールしたのち、以下のように設定を行った。

configure system interface pattern eno*,ens*
configure lldp portidsubtype ifname

ネットワークスイッチ側からLLDPネイバーを表示すると以下のようになった。Chassis IdにはMACアドレス、Port infoにはLinux上でのインターフェイス名が見えることが期待値であったが、ハードウェア固有の値が表示されている。

{master:0}
me@myswitch> show lldp neighbors
Local Interface    Parent Interface    Chassis Id          Port info          System Name
xe-0/0/8           ae2                 39373638-3935-5099-4E99-303330309999Embedded ALOM, Port 1
xe-0/0/10          ae2                 39373638-3935-5099-4E99-303330309999PCI-E Slot 1, Port 1
{master:0}
me@myswitch> show lldp neighbors interface xe-0/0/8
LLDP Neighbor Information:
Local Information:
Index: 147 Time to live: 121 Time mark: Tue Jun  2 06:27:34 2020 Age: 12 secs
Local Interface    : xe-0/0/8
Parent Interface   : ae2
Local Port ID      : 521
Ageout Count       : 0

Neighbour Information:
Chassis type       : Locally assigned
Chassis ID         : 39373638-3935-5099-4E99-303330309999
Port type          : Mac address
Port ID            : 00:00:5e:a2:72:00
Port description   : Embedded ALOM, Port 1

System Description : HPE ProLiant DL360 Gen10

また、サーバ側からLLDPの自身の情報とネイバーの情報を表示すると、ChassisIDやPorIDが正しく設定されていることがわかり、ネイバーが見えていないこともわかる。スイッチ側の設定はスイッチ間のLLDP設定で正しく表示できていることが確認できていたため、これはスイッチからのLLDPDUがLinuxのレイヤーまで届いていないということになる。

root@myserver:~# lldpcli show chassis
-------------------------------------------------------------------------------
Local chassis:
-------------------------------------------------------------------------------
Chassis:
  ChassisID:    mac 00:00:5e:7b:a4:10
  SysName:      myserver
  SysDescr:     Ubuntu 18.04.3 LTS Linux 4.15.0-55-generic #60-Ubuntu SMP Tue Jul 2 18:22:20 UTC 2019 x86_64
  MgmtIP:       10.102.253.54
  MgmtIP:       fe80::ac91:afff:fe1f:aee0
  Capability:   Bridge, on
  Capability:   Router, on
  Capability:   Wlan, off
  Capability:   Station, off
-------------------------------------------------------------------------------

[lldpcli] # show interfaces ports eno5
-------------------------------------------------------------------------------
LLDP interfaces:
-------------------------------------------------------------------------------
Interface:    eno5, via: unknown
  Chassis:
    ChassisID:    mac 00:00:5e:7b:a4:10
    SysName:      myserver
  Port:
    PortID:       ifname eno5
    PortDescr:    eno5
  TTL:          120
-------------------------------------------------------------------------------
root@myserver:~# lldpcli show neighbor ports eno5
-------------------------------------------------------------------------------
LLDP neighbors:
-------------------------------------------------------------------------------

生のハードウェアIDが表示されていたため、BIOSの設定を疑って漁ってみたが、見つからなくて途方に暮れたので友人たちに訪ねてみると早速ヒントを貰った

Intel NIC (i40eドライバ)でLLDPのオフロードが有効になっているようである。

centos6 - Disable internal Intel X710 LLDP agent - Server Fault

バージョン2.3.6以降のi40eのドライバーではethtool経由でLLDPオフロードを無効にできるようであるが、Ubuntu18.04で使っていたドライバはそれより若いバージョンであったため、 debugコマンド経由で無効にする方法を利用した。以下のようにdisable-lldp-offload.sh という名前でスクリプトを配置し、再起動時でもオフロードの無効化が自動でできるようにするため、/etc/cron.d/lldp から@rebootで呼び出すことにした(systemdではなく)。

#!/bin/bash 
i40e_path=/sys/kernel/debug/i40e
for dev in $i40e_path/*; do 
    [ -e "$dev" ] || break 
    echo lldp stop > "${dev}/command”
done

@reboot root sleep 60 && /root/disable-lldp-offload.sh

スイッチ側からも無事に正しい情報を参照できるようになった。

{master:0}
me@myswitch> show lldp neighbors
Local Interface    Parent Interface    Chassis Id          Port info          System Name
xe-0/0/8           ae2                 00:00:5e:7b:a4:10   eno5               myserver
xe-0/0/10          ae2                 00:00:5e:7b:a4:10   ens1f0             myserver

ありがとう @markunet !!

JANOGのCode of Conduct

f:id:yuyarin:20191224033223g:plain

JANOG

こんにちは。JANOG(日本ネットワーク・オペレーターズ・グループ)というコミュニティで運営委員をやってるゆやりんです。

adventar.org

コミュニティ•カンファレンス運営 Advent Calendar 2019ということで、JANOGの運営について紹介しようと書いていたら、あまりにも長大なポエムが出来上がってしまったので、ほとんど捨てて要点を絞って最近話題のCode of Condactについて話したいと思います。

JANOGは7000名のネットワーク技術者のコミュニティ

日本ネットワーク・オペレーターズ・グループ(JANOG)はネットワーク運用者が集まる技術コミュニティです。インターネットはいろいろな組織や事業者のネットワークが相互接続することで形成されています。そのためそれを運用する技術者たちも繋がりを持ち、組織の壁を超えて技術的な情報を交換したり、共通の課題を解いていく必要があります。JANOGはそのためのコミュニティです。
1997年に北米のNANOG (North American NOG) に参加して刺激を受けた技術者たちが立ち上げ、今年で22年目になります。会員はメーリングリストの登録者数で数えており約7000名です。

活動のメインは年２回のMeeting

JANOGでは年２回ミーティングを開催しています。例年1月と7月に開催しており、最近では水曜の午後から金曜日までの2日半の開催になっています。
最近ではJANOG44ミーティングが神戸で開催され過去最高の1602名が参加しました。

f:id:yuyarin:20191224011527p:plain

JANOG44ミーティング in 神戸

参加者は増え続けてついに1600名に

f:id:yuyarin:20191224011538p:plain

JANOGミーティングの参加者数の推移

私が学生のときに初めて参加したJANOG26の時期は都内だと700名、地方だと300-400名程度の出席でした。それがここ５年くらいでどんどん増えてJANOG41で1000名超え、今回のJANOG44では1600名になりました。

JANOGのCode of Conduct をつくった

1600名も参加するミーティングともなると、色々な人が参加することが想定されます。JANOGでは2016年6月頃から検討をはじめて、2017年8月に「JANOG行動規範」として公開しました。

https://www.janog.gr.jp/doc/janog-comment/jc11.txt

JANOG行動規範


JANOGの価値は幅広い参加者の知見と興味、率直な意見交換に支えられています。
これはメーリングリストやミーティング、ワーキンググループなど、
JANOGがその目的を達成するための様々な活動の全てに共通しています。

それぞれの参加者は、異なる背景や状況、意見を持ちうることを認識し、
お互いに思いやり尊重しあいましょう。あらゆる嫌がらせや誹謗中傷、
反社会的行為は許容されません。この行動規範に反する行為や言動に対して、JANOG運営委員会は当該人物の退出や除名などの必要な措置を講ずることがあります。

共に楽しみ、共に課題を乗り越え、充実したコミュニティを作っていきましょう。

以上

なにか個別の問題が発生したので制定したという経緯ではなく、海外を中心に他のコミュニティでCoCを制定することが当たり前の流れになってきており、JANOGでもこれが必要になるだろうという判断を行いました。

ドラフトを策定して公開、次のJANOGミーティングで説明、意見募集。その次のJANOGミーティングのオープンマイクで採択という流れを取りました。そのため検討から約１年を要しています。

他のコミュニティのCoCを参考にした

CoCは同じく運営委員の金子さんや松崎さんが中心となって策定をしていただきました。策定にあたって他のコミュニティ、特にネットワーク系でアジア圏でカンファレンスを行っているAPNICやAPRICOTなどを参考にしており、APNICのCoCをベースに作成しました。

前向きなCoCを作ろう

なぜCoCが必要だと判断したのかは、松崎さんがJANOG39で開催してくれたJANOG行動規範BoF (Bird of feather, 同好会)の資料でも書かれている通り、

  • 僕たちがどういう価値観や倫理的指針を持って活動しているか明文化しておきたい
  • 嫌がらせ（ハラスメント）は許されない行為だと明確にしておきたい
  • この思いに賛同する人がどんどん参加して、このコミュニティが発展してくれると嬉しい

という３点が主な理由です。会員やミーティング参加者の行動を厳しく縛るような後ろ向きな規約を決めるのではなく、参加する人が安心して参加できるように前向きなCoCにしたいと作る際に方針を決めました。

JANOG39 :: [JANOGCOC] コミュニティの行動規範 - JANOGはどうする？

JANOGというコミュニティがどのような価値観を持っているかを表明するとともに、ハラスメントに対して許容しない、ハラスメントがあればアクションを取るということを明文化することで、そうした行為が行われた際にミーティング実行委員（スタッフ）のみなさんが自発的に行動できる指針を示しておくという効果ももあります。

CoCはコミュニティの価値を高めるために必要

「昔はそんなもの必要なかった」というご意見もいただきますが、我慢させられ泣き寝入りしてしまう人もたくさんいたのではないかと思います。

コミュニティ運営者がCoCを作ることで、そうしたハラスメントを受けた方をケアし、またハラスメントを抑止することで、コミュニティの価値や魅力を上げていくことに繋がります。それによりコミュニティが活性化して会員や参加者もその恩恵を受けることができるようになり、良い循環が生まれます。

検索するとCoCの雛形なども公開されていたりするので、まだCoCを制定していないコミュニティ運営者はぜひ制定してみてください。

NTTComを退職してNTTComに入社します

TL;DR

平成から令和への時代の変遷とともにNTTComを退職し、スペシャリスト社員としてNTTComに入社し、新たな人生を歩みます。

仕事としてはSDNのテックリードとしてNTTComのクラウドのSDN基盤のStabilityとScalabilityの向上に引き続きチャレンジしていきます。

一階級飛び級して課長相当のロールの仕事をして、終身雇用と年功序列と労働組合の轍から外れる人生を歩むことになります。お給料もあがります。

これからは、短期的にはテックリード→アーキテクト/エンジニアリングマネージャー→CTOのような感じで、NTTComの中でのエンジニアのキャリアアップのロールモデルとして活躍し、道を切り開いていきたいと思います。

長期的にはNTTComに限らず、ネットワークのおもしろい案件を渡り歩いて請け負っていく、エンジニアやエンジニアリングマネージャーとして生きていこうかなと思います。おもしろい案件があればいつでもお声がけお待ちしております。

f:id:yuyarin:20181221093456j:plain

どしたん？

実は年明けから転職活動をしていました。理由としては

  • 知り合いから一緒に仕事をしたいと誘われていたおもしろい案件が複数あった
  • 年末のイベントで「エンジニアの給与が低い」という意見に対して社長が「自分の市場価値を考えろ」と煽ってきたので測りたくなった（最下部に補足追記あり 2019-05-01 18:30）
  • 転職活動を経験しておかないといざという時に失敗すると思ったので、全部落ちてもいいからとりあえず経験値を積もうと思った
  • 年末年始と社内で不信感の溜まる出来事が立て続けに起きた
  • 大きい仕事が一区切りした
  • ちょうど切りの良い年齢だったので、年末年始の考える時間で、自分の人生はこのままでいいのかと不安に思った
  • NTTの中でこのまま出世するにしても、他の会社を知らないまま偉くなりたくないなと思っていた

という要因がたまたま同じ時期に重なったというのが大きいです。

いくつかの会社から無事に内定をいただきまして、うち１社でネットワーク＆ソフトウェアエンジニアとして最強のデータセンターネットワーク＆クラウド基盤を構築しようと、転職する気満々で円満退職に向けて社内調整を行っていたのですが、いろいろなことがあって、結果としてNTTComに残ることにしました。内定を頂いた会社の皆様にはご迷惑をおかけして本当に申し訳ないです。

何があったん？

もともと社内でたくさんの先輩方から目をかけて頂いていたので、転職に際して強い引き止めがあることは予想していました。なので自分が何がやりたくて辞めるのか、なぜその会社に行くのかをちゃんと説明して、納得はしてもらえないだろうけど、理解はしていただいて、それから辞めようと思い、お世話になった方々に仁義を切って回っていました。

そこにこの記事ですよ。

style.nikkei.com

「おしかけラグビー」というキャッチーなフレーズが話題になってTwitterやはてなのエンジニア界隈で大炎上したわけです。辞めるつもりの会社とはいえ愛着はあったし、今辞めたらラグビーボールを投げつけられたから辞めたと勘違いされかねないので、これはいかんとすぐに火消し記事を書いたわけです。

yuyarin.hatenablog.com

そしたらはてブでも反響があり、ねとらぼの記事にもなり、誤解はある程度解けて、徳力さんにもべた褒めされたわけです。

nlab.itmedia.co.jp

news.yahoo.co.jp

これらの記事は社内でも色んな人に見られて、感謝や好意的な反応、応援をいただきました。そして僕は内心「次の記事、退職エントリーなんやけどどないしょ…」って冷や汗をかきつづけていました。

こんな出来事がタイムリーに起きてしまった結果、結論から言うと、この記事で言及されている新キャリアパスの「スペシャリスト社員」として、キャリアップしていくモデルケースになっていくことにしました。

どゆこと？

記事にも書かれている通り、スペシャリスト社員自体はもともと社内に密かにいたのですが、誰がスペシャリスト社員なのかも公にされていない状態でした。また、スペシャリスト社員自体が正社員の劣化版のような状態で始まっていました。しかしながら今は業界他社と競争力のある環境で人材を確保するための枠であり、多種多様なキャリアアップを実現するための制度となろうとしています。

仰々しくいいましたが平たく言うと、やっとIT系企業では普通の雇用が始まったということです。スタートラインに立っただけなんですが、この一歩はNTTのようなトラディショナルな日本の大企業にとっては大きな転換だと感じます。

そして私自身がこの制度で転身し、後輩のエンジニアたちの道標となるということが、NTTComを変えて優秀な若手エンジニアの環境や待遇を良くする方法を悩んでいた中で、非常に魅力的な選択肢として心に響いたので残る決心をしました。

その決心の土台として、今の仕事がチャレンジングで面白かったのと、今のチームが最高に良いチームだったことは非常に大きかったです。

なんで退職？

スペシャリスト社員になるために雇用替えを行うので、一旦退職という扱いになります。退職金もいただきます。そしてNTTの終身雇用＆年功序列のシステムから外れます。

そういやこれまたタイムリーに経団連会長が終身雇用のギブアップ宣言をされましたね。NTTの業務自体はなくなるとは思いませんが、経営する主体は変わることはあるんじゃないかなと思います。その時にいくらNTTとはいえ勤続年数が上がるに連れて給与が上がるシステムは全くもって期待できないと思います。

そしてスペシャリスト社員ということで職務型（いわゆるJob Description型）の雇用体系に変わります。なので今のポジションが無くなったら、どうなるかわかりません。

というわけで僕自身は一度終身雇用を捨てた身であって、転職先がたまたま同じ会社だっただけという認識です。なので常に転職市場に繰り出すことは考えています。

給料あがったの？

あがりました。他社とある程度の競争力のある水準まであげていただきましたし、職位としても非管理職の役付きになってすぐにもかかわらず、管理職である課長相当のロールにあげていただきました。次の職位にあがるためには３年とか一定期間を待って試験を受けないといけない中、実質一階級飛び級したことになります。これは実力さえ示せば勤続年数に関係なく上の役職相当の仕事ができるということで、トラディショナル・ジャパニーズ・カンパニーにおいては大きな変化だと感じています。逆に言えば育成の猶予があった３年をすっ飛ばして、その職位としての結果を求められる過酷な状況に自分を追い込んだということです。

また、スペシャリスト社員＝給与アップというわけではありません。JDベースの仕組みですので、当たり前の話ですが、そのポジションの会社にとっての重要性や、その人に期待する役割などによって給料は決まります。

そのような結果、私より職位が高い人に比べて額面上は高い給料になっている場合もあります。NTTのような序列のある会社の中でこの状況は精神的に結構キツイです。でもどこかでこの逆転現象を起こさないと、自分より若い人たちの給料も上がらないと思ったので、自分がこの役目を買って出ることにしました。

終身雇用から外れたので退職金とかはありませんし、住宅補助や扶養手当のような一部の福利厚生もありません。そしてなにより将来の保証がありません。その分を考えた時に本当に良かったのかどうかはまだわかりません。が、どうせ辞めるつもりやったんやからええやろと吹っ切りました。

あがったとは言っても id:kumagi よりは安いし、彼らはそこから上がっていくことを考えると、まだまだGAFAへの流出は防げない水準であると関係者には伝えてあります。僕が内定を頂いき転職しようとしていたところはGAFAではなく国内企業です。たまたまこういう特殊なきっかけがあったので私の流出は防げましたが、待遇や環境を総合的に考えると、実は国内企業への流出を防げる水準にも全然なっていないということは言っておいたほうが良いかもしれません。

何の仕事やんの？

そもそも今まで何の仕事をしてるのかあまり公にしてませんでしたが、エンタープライズ業界向けのクラウドサービスのSDN基盤を作ってました。ひとまずはこれまで通りの仕事内容になるのですが、テックリードの肩書も正式にもらえる予定なので、引き続きチームを引っ張ってSDN基盤のSREを実現してStabilityとScalabilityの向上にチャレンジしていきたいと思っています。対外活動も引き続きやっていきます。

Why NTTCom？

NTTComは国内でIaaS/クラウドの開発ができる事業者の中で最大規模だと思っています（ちなみにNTTドコモもやってるよ）。AWSやGCPの開発をやりたいと思うと、どうしてもアメリカの本社に行かないといけないですよね、知らんけど。今のチームにJoinしたときに中身を知って「え？NTTComがこんなにすごいサービス作ってるの！？」ってびっくりしました。

自分たちで開発しているからこそ、障害が起こると自分が日常で使っている色々なシステムやサービスが止まってしまう怖さや責任感もありますし、だからこそ「NTTComのクラウドのネットワーク全部俺」って言える楽しさもあります（もちろん私だけじゃなくてみんなで作ってますが、そういう気持ちでいられるということです）。それを結構魅力に感じています。

まだまだ直さないといけないところはたくさんあるし、日本企業の古い文化や体質が残っているところもたくさんありますが、労働組合が強く労働者が守らていて休みも取りやすい超絶ホワイトな会社であるというNTTの従来型の良い面も保ちながら、オフィスも新しくなったし、リモートワークもできるし、フレックス勤務もできるし、副業もできるし、Job Description型の雇用体系もできるし、会社自体も時代に合わせてここ数年で劇的に改善しています。

従来どおり適度な仕事で安定した人生を送りたい方にはもちろん、不安定な環境でもいいので自己実現したい尖ったエンジニアにも、両方の人たちにおすすめできる会社になってきています。 

f:id:yuyarin:20190430212407j:plain

※ 自席ですが狭く見えるのは写ってはいけないものが写らないように狭い範囲だけを撮っているからです。なおMacBook 1画面派でモニターはあんまり使ってませんので私はデュアルディスプレイにはしてません。ぬいぐるみは「おしかけぷよぷよ部」を始めようと思ったからです。

さいごに

この件についてはたくさんの関係者の方に動いていただきました。本当にありがとうございました。

ところでお客様の中に、ネットワークのすべての分野に精通していて、クラウドコンピューティングが好きで、データセンターネットワークを作るのが好きで、特にBGPとかEVPNとかVXLANとかが好きで、でもVRRPとかSTPとかARP/NDとかエッジ・ホスト側のネットワーク技術も好きで、tcpdumpでパケットレベルのデバッグをするのが好きで、C++とPythonの読み書きデバッグが好きで、Linuxのカーネルやネットワークスタックが好きで、OpenStackが好きで、CassandraとかRabbitMQとか分散ミドルウェアが好きで、docker/k8sとかのコンテナ技術が好きで、英語をしゃべるのが好きなエンジニア、いらっしゃいましたらTwitterとかで @yuyarin までご連絡ください。

それでは令和時代もよろしくお願いいたします。

 追記

『「エンジニアの給与が低い」という意見に対して社長が「自分の市場価値を考えろ」と煽ってきた』という部分にネガティブな反応が見受けられたのですが、まずこれはこれは私個人に対して向けた言葉ではなく、意見を出した人個人に「君は市場価値がない」という意味で言ったわけでもありません。

社長は社会人として当たり前のことを指摘したに過ぎないと思っています。何の根拠もなく給料を上げろというのは筋が通っていませんし、NTTヨーロッパの人の話を聞いていても他社提示額を以って給与交渉をするようですので、そのような方法を以って話をしようという意図だったのだと思います。社長からすると、会社全体で見たときに市場価値より高い給料で雇われている人がたくさん見えるのだと思います。

そのようなわけで、私も反発して感情的に転職をしようと思ったわけではなく、なるほど確かにと理性的に納得して、それを確かめるために転職市場に繰り出そうと思った次第です。

追記２

有益情報をいただきました！

 

NTTCom社員は本当にラグビー部員におしかけられているのか？

TL;DR

そんな事実は無いし、技術職も希望をちゃんと伝えればちゃんと配属されると思うので内定者・就活中の学生の皆様は安心してね。

この記事は何？

style.nikkei.com

b.hatena.ne.jp

この記事がはてなブックマークやTwitterのエンジニア界隈で大変な話題になっているけど、事実と違うことが書かれて炎上しているのが中のエンジニアとして大変悲しいですし、内定者や就活中の学生のみなさんが不安になってしまうと思ったので、ちゃんと解説するいわゆる火消し記事です。

この記事は勤務時間中に上司の許可や広報の許可を得ずに書いていますので、普通の会社なら怒られるかもしれませんが、うちの会社は多分大丈夫だと思います。

あくまで一社員とその周囲からの観測範囲をベースにして書いているので、見え方が違うこともあるかもしれませんが、そこはBGPの経路情報と同じでご容赦を。

炎上しているポイント

主に以下の２点で炎上していると認識しています。

ポイント１：技術職がどこに配属されるのかわからない

「技術職として採用する場合、『どの部署に配属されるかはわかりません』と言ってきました。ところが、それだと『じゃあ御社には行きません』といわれてしまうケースも多くて。採用の環境の変化を感じます。だからこそ、色々な経験ができるのが当社のよさだと伝えていかなければならないと思っています」

ポイント２：業務中にラグビー部が突入してきてボールを投げてくる

職場に突然、ラグビー部員がわーっと入っていって、社員にボールをパスしたり、体を動かしてもらったりするんです。

要約

  • 技術リクルーティングの枠組の中で採用された技術職は配属先はちゃんと希望されたところに行けるようになっています。
  • 「おしかけラグビー」はラグビー部員が広報する活動のこと。色々な企業や団体に招かれて行っているみたいですが、NTTコム社内で突然ラグビー部がラグビーボールを投げつけている事実はありません。

技術職の配属について

私が入社した2011年ごろは記事に書いてあることは確かに本当でした。正確には技術職という枠組みもなくて、一律「新入社員」という扱いでした。その中で意にそぐわない配属をされて涙を流した同期もいました。

しかしここ数年は技術リクルーティングという枠組みを作って採用活動を行っており、こちらの枠組みでは、配属先の部署はある程度コントロールされて「約束通り」になるように頑張っています。クラウドのベアメタルの開発、クラウドのSDNの開発、高速ルータの開発、OCNの開発、といった感じで、ネットワーク、クラウド、セキュリティ、アプリケーションなど複数の分野で技術の専門家を採用しています。

もともとの採用方針がいわゆる日本企業的な「コミュ力重視」の採用で、そういうのが苦手だけどとても優秀なエンジニアがNTTComに入社しなくなってしまうのを避けるためのパスです。大学によっては推薦の枠組みがあるので、その時はご相談ください。

少なくともこの採用パスに入ることができる実力を持った腕利きのエンジニアには「何処に配属されるのか分からない」みたいな状況は待っていません。

『スペシャリスト採用』のような仕組みがあってもいいのかもしれませんが、現実には3年ぐらいたってから選べるようにする方がいいかなと思っています。

という部分については私も納得行かないので、技術リクルーティングで採用されたエンジニアは１年目からスペシャリスト採用になる選択肢を持てるように声を上げていきたいと思います。

ラグビー部がラグビーボールを投げてくる件について

今までのNTTComでの業務時間中にラグビー部からラグビーボールを投げられたことはありません。もしかして僕は社員じゃなかったのかと不安になりましたが、エンジニアのSlackでアンケートを取ったところ21名（のべ在籍年数128年）から即回答があり、業務時間中にラグビー部から突然ラグビーボールを投げられた経験は誰一人ありませんでした。

親切な方が調べてTwitterで発信してくださっています

 

そのようなわけでこの部分については中の人的には「そんなことやってへんやろー」っていう事実が歪んで伝わった程度の記事が、思いの外のキャッチーさで炎上してしまったという感じです（もしかしたらどっかで本当にやってるのかもしれないけど）。

まぁ、大丈夫です、ラグビーボールは飛んできません。

f:id:yuyarin:20190328113747p:plain

この記事で本当に伝わってほしいこと

外資IT系の友人たちからは「やっと10年前だな」という言葉を頂いていますが、これは本当にそのとおりです。私の見方としては「やっと"まとも"な改革ができる人が人事部長になれる時代がやってきた」のです。

山本恭子さんは数々の抵抗勢力に負けずに改革を推進して、社員が働きやすい会社を作ってきています。彼女は我々エンジニアの希望の星でもあります。なのでラグビーの件で「こんな人がトップだから」と言われるのはとても悲しいですし、より制度がよくなるように助言やサポートはしていきたいです（この記事も一つの形です）。

在宅勤務やフレックスなど働きやすい仕組みも整ってきましたし、能力型の「スペシャリスト社員制度」も始まっていますので、腕に覚えがあればGAFAに匹敵するぐらいの給与もでるかもしれません、知らんけど。制度などの面では本当に働きやすく、ここ１年で劇的に良い職場になってきました。

記事でも言及されている通り、課長が勤務管理で忙しすぎるとか、まだまだ改善しないといけない面もたくさんありますが、それを人事部はちゃんと認識していて、なんとかしようと頑張っています。出さなくても良いネガティブな内容を敢えて出しているというのは「これから変えていくという有言実行のメッセージ」だと捉えています。

ところでお前誰？

NTTComでエンタープライズ向けのクラウドサービスのSDN基盤を開発してるよ。ネットワーク機器の検証もするし自分たちでコードも書くよ。開発環境もMacBook ProでSlack、G Suite、Confluence、Jira、GitHubだよ。今はスケーラビリティを上げつつもSDNのSREを実現して安定したネットワークが作れるようにチームで頑張ってるよ。

その前はインターネットエクスチェンジのJPNAPでネットワークエンジニアとソフトウェアエンジニアの両方をやってたよ。ガリガリソフトウェアを書いてネットワーク運用の自動化とかやってたよ。バックボーンの設計とかもやってたよ。

ネットワークとソフトウェアの両方ができるいい会社だよ。

まとめ

他の会社の炎上記事もこんな感じなのかなぁって思うと、話半分に読むのが良いのかなと思いました。

宣伝

NTTの人たちがやっているエンジニアリング的なお話に興味がある方はどうぞ

fukabori.fm

FAQ

映像があるんだけど？

www.youtube.com

この件については詳しくは知りませんが、場所はNTTCom社内ではなく浦安市役所だと思います。さすがにそこにいきなりおしかけるのは不法侵入になりますので、先方から招聘いただいて実施したイベントではないかと思います。その場合は、社内でいきなりラグビーボールをぶん投げてくるのとは事情が全く異なるかと思います。

取材場所はラグビーチームのシャイニングアークスの拠点であるアークス浦安パークだと思います。そのご縁で浦安市役所に伺ったのかと思います。

ちなみに浦安市にNTTComの事業部のオフィスはありません。

各部門の紹介 | NTTコミュニケーションズ 企業情報

たった21人の調査？

大手町プレイスっていう新築のビルにオフィスを移転しました！１フロア300-400人で仕切りもない大部屋なのでオフィスにラグビー部員が突入してきたらすぐわかりますよ。そういう状態で少なくともサービス開発・エンジニア系のフロアでそういった事象は21人の目で観測されなかったということです。ご指摘の通りSlackにいなさそうな部署の人のフロアで突入があったら、わかりません。営業系のフロアとか、社長室とか。

https://developer.ntt.com/sites/default/files/blog_images/MVIMG_20181218_182326.jpg

NTT Com Tech Night #1を開催しました! (レポート) | NTT Communications Developer Portal

火消し業者？

そうそう、NTTComでは副業もOKになりました。副業ってことにしてお金貰えばよかった…！