ネットワーク運用自動化の実際〜現場で使われているツールを調査してみた〜
- 1. ネットワーク運用自動化の実際 〜現場で使われているツールを調査してみた〜 BIGLOBE Inc. Taiji Tsuchiya 2016/6/27 NetOpsCoding#3 1
- 3. NetOpsCoding Advent Calendar 2015 http://qiita.com/advent-calendar/2015/netopscoding 2016/6/27 NetOpsCoding#3 3 SSH Telnet Telnet expect expect Telnet Telnet
- 9. アンケートしてみました 2016/6/27 NetOpsCoding#3 9 • 「ネットワーク運用でどんなツール使ってますか」 – 期間：6/10(金)〜6/24(金) (２週間) – 質問数: 28問 ( 所要時間10分程度) – 回答者数: 28名 – 周知先: JANOG ML, SNSでのつぶやき ご協力ありがとうございました！
- 10. アンケート項目 • ネットワークトラフィック監視で使っているツール • ネットワーク装置のアラート監視で使っているツール • コンフィグレーション作成 および作業手順書で 使っているツール/手段 • ネットワーク装置の設定作業で使っているツール/手段 • ツール開発体制 • ネットワーク運用業務にOSSを利用することの印象 • 今作りたいツール/欲しいツール 2016/6/27 NetOpsCoding#3 10
- 13. Q.ネットワークトラフィック監視ツール への質問 • どんなツールを使っていますか？ • 満足度を教えて下さい • 満足している点/不満に感じている点 を教えて下さい • 今後使ってみたいツールがあれば教え て下さい 2016/6/27 NetOpsCoding#3 13
- 16. • Cactiに満足している点 – 複数トラフィックを一覧画面を見ることができる – ツリー表示が可能 – UIがわかりやすい – 以前はmrtgを利用していた点もあり、CactiはWebインタフェースで 設定可能な点で満足している。 – 扱いやすいUI – グラフが綺麗で参照操作もある程度直感的, 割と多機能(プラグイ ンが豊富) – 外部からの制御を可能にするphpが用意されている→ある程度の自 動化ができるwethermapによる可視化が便利 – 時間範囲を指定してグラフ表示させることが容易。 – テンプレートを利用した監視対象機器追加が容易。 – サンプリングレートを1分に設定することが可能。5分平均では見えな いバーストが見えるため。 – バグ/トラブルが少ない 2016/6/27 NetOpsCoding#3 16
- 17. • Cactiに不満を感じている点 – カスタマイズしたいグラフを作るときが難しい＆手間がかかる – 積み上げグラフなど、グラフをカスタマイズする方法が難解 – テンプレート自体の修正方法がわかりにくかった。 – テンプレートが複雑 – 見た目が古臭い – rrdなので過去データが丸められる – モニタリング項目が増えるとスケールしない – 特定時点でのトラフィック値が見づらい (目を凝らさないといけない) – 機器追加時の新規登録が面倒。 – なれたツールがあるので、新規で新しく導入しなくなる点 – 標準提供の Cli php を使う以外は GUI を使わざるを得ないので、デバイス 更新や登録の自動化には一工夫必要(かっちりと固めた統一ポリシーをシコ シコと GUI で作って、登録は Cli php を使って一括でやるだけ…とか) – システム冗長構成にし辛い – 動作の重さ – パフォーマンス、検索条件に正規表現を使えない – php 2016/6/27 NetOpsCoding#3 17
- 18. • Zabbixに満足している点 – オープンソース – 基本機能だけでわりと便利 – とりあえず使えるよ、動くよ。というところ – GUIがJSなのでリアルタイム性がある（Cactiは画像なの でページのリロードが必要） – 監視とアラート上げを同一ソフトウェアで実施できる – Ciscoであれば一通りのZabbixテンプレートは公開されて いるので、機器ごとの設定を深く考える必要がない 2016/6/27 NetOpsCoding#3 18
- 19. • Zabbixに不満を感じている点 – 大量のノードやホストグループを管理する場合、ダッシュボードの表示 で監視が厳しい（煩雑なため） – 機能が豊富過ぎる – なんでもできるが設定が複雑 – データが増えると重くなる – テンプレートの作り方 – グラフをまとめて見る画面（Screen）をGUIにて構築するのがつらい – Cactiのように複数グラフをひとつのページで見れない（スクリーン機 能でできるが設定が面倒） – UIがひどい。画面が直感的でなさすぎて、見たいものを見るまで迷う – テキストで編集した設定をGUIからインポートしなければならなくてつ らい – APIの事例が少ない – telnetしたりするとカスタムコマンドが必要になってくるが、その管理 どうする問題 2016/6/27 NetOpsCoding#3 19
- 20. • MRTGに満足している点 – 仕様がシンプルで扱いやすい – 設定が単純であるため、スクリプトなどによる自動化のカス タマイズしやすい – チューニングの情報が広く手に入る • MRTGに不満を感じている点 – 古いデータを遡るのがつらい – 流量だけで細かい情報(flow)などは、別のシステムが必要 – ダイナミックに時間を変更したり、複数のグラフと合成する など、新しいグラフツールにある機能が実装されていない ため、補完するツールが別に必要になっている – いささか古さは否めない 2016/6/27 NetOpsCoding#3 20
- 21. • Muninに満足している点 – CactiやZabbixとは異なり、設定がテキストベースなため、設定が バージョン管理システムで管理できる点 – 導入の容易さ、数値で取れる監視項目であれば何でも監視でき る柔軟性 – 設定が楽 – 後から見られる、セットアップが簡単 • Muninに不満を感じている点 – プラグイン周りの概念が若干トリッキー – グラフのカスタマイズ性が低い (一応ブートストラップのラッパー はあるらしい) – 死活監視、閾値超えの通知設定がやや面倒 – 詳しい設定を行うときに属人的になってしまう – 難しいことができない 2016/6/27 NetOpsCoding#3 21
- 22. • LibreNMS – 満足度: やや満足 – 満足： とりあえずSNMP投げておけば良い感じに グラフ生成してくれるところ – 不満：デフォルトだとSNMPとりすぎでスイッチへ の負荷が高い • SNMPベースによる内製ツール – 満足度: やや不満 2016/6/27 NetOpsCoding#3 22
- 23. ネットワークトラフィック監視において 今後使ってみたいツール • Zabbix, Cacti といった高度なツールを使ってみたい、 • Zabbix。トラフィック監視だけでなくあわせていろいろできそうなため。 • ZabbixおよびNetFlowによるトラフィック可視化を検討中 • Cactiのようなデータを蓄積するものと、作業用に秒単位でのリアルタイムグラフがほしい • Munin (設定は基本 cli で済むし、カスタマイズしたデバイスのテンプレート作成もチョロい 、ただ Cacti ほど多機能ではないので同等のことをするのに作り込みが必要) • NetFlow Analyzer • Grafana • 流量を可視化できるケーブル（が、欲しい） • トラフィック統計からDDoSを教えてくれるツール • Sensu (API が強そう) • IIJ GRI (とにかく設定が楽。IFは SNMP で総なめするので、それが楽な反面、機器によ っては不都合が…) • WebAPIがほしい • 閾値超えでJSONのpush通知がほしい • 登録とか簡単にしたい • 機器情報を自動登録できるツール 2016/6/27 NetOpsCoding#3 23
- 24. ネットワークトラフィック監視ツール 回答まとめ • 現用ツールに65%以上が満足/やや満足 • 望まれている機能 – 容易なグラフのカスタマイズ (トラフィック積算グラフが作りたい?) – 複数ノード登録の自動化のしやすさ – 複数グラフの一覧性(１ページで見たい) – Flow情報によるトラフィック情報の可視化 2016/6/27 NetOpsCoding#3 24
- 25. Q.ネットワーク装置の アラート監視への質問 • どんなツール/手段を使っていますか？ • 満足度を教えて下さい • 満足している点/不満に感じている点 を教えて下さい • 今後使ってみたいツールがあれば教え て下さい 2016/6/27 NetOpsCoding#3 25
- 27. Syslog + メール 満足度 2016/6/27 NetOpsCoding#3 27
- 28. • Syslog + メールに満足している点 – syslog サーバなら誰でも設定・運用できる – メールなら、Slack などの SaaS をポリシ的に使えない環境でも 仕組みがシンプルなので、独自スクリプトで色々カスタマイズしやすい – 標準的な機能を使う為、実装が楽 – まぁまぁメールすぐ来る – 仕組みが単純なため異なるベンダー機種への対応や、新しい機種 に対応しやすい – 最低限アラートを受け取る分には困らない。procmail でなんとかなる – syslogを受けるサーバーだけあれば、とりあえず監視はできるという 手軽さ – 監視対象機器側の設定も簡単にできるものが多い – ネットワーク機器のアラートとしては十分。 2016/6/27 NetOpsCoding#3 28
- 29. • Syslog + メールに不満に感じている点 – 量が多いとメール見落とす – 大規模な障害が起きると大量のログの海で溺れることになる – 通知が多すぎて実質機能してない – メールに送られてきても緊急時気づかない – メールではリアルタイム性に欠ける – メール中心で仕事したくない – 相関分析がしにくい (メッセージ A の後に、メッセージ B が出力されたら正常なので 通知しない、B が出力されなかったら異常なので通知、とか、10秒で5回以上メッセージ C が出力されたら異常とみなす、とか) – 最近は特に JUNOS が debug みたいな error ログを吐きすぎ(commit 時とか)で、 仕分けが面倒くさ過ぎる – メールフォーマットが統一されてなく、都度人が判断する必要がある – 信頼性が低い – フィルタ設定ミス/漏れによる不要なアラート – syslogサーバの負荷分散 – syslogサーバーがSPOF – 過去ログの検索が難しかったり、時間ベースの相関分析ができなかったりしている – サービス監視では、ツラ過ぎる、スマートにしないとね。簡単な方法で。 – メールサーバを自前運用できないと非常に厳しくなる 2016/6/27 NetOpsCoding#3 29
- 30. • WhatsUpGold – 満足度: やや満足 – 満足： だいたい思った通りに動く – 不満： （自分で設定しないが）デバイスが多くて設定が大変そう • SNMP Trap – 満足度: やや満足 – 満足： NW機器側から通知してくれるので、ポーリング間隔などの設 定が不要 – 不満： OIDがないイベントは通知できない • 自作シェルスクリプト – 満足度: 満足 – 満足: 満足がいくまで自分の思い通りに作りこんでいるので • Syslogベースによる内製ツール – 満足度: やや満足 • syslog + 目grep – 満足度: やや不満 – 満足：なし – 不満： syslogで集めてはいるが、時々分析する程度2016/6/27 NetOpsCoding#3 30
- 31. ネットワーク装置のアラート監視において 今後使ってみたいツールがあれば教えて下さい。 • Fluentd + Elastricsearch • fluentd + 検索システム + kibana&Slack相当を検討 • Mackerelみたいに、サーバーの面倒を見なくて良いシステム • NetCrunch • Slack のクローン版 (本家が SaaS であることが問題、な環境で は) • アラートのレベル毎に通知方法を分けたい (warning -> チャット clitical ->電話) • Ｚａｂｂｉｘ • メールおまとめするもの 2016/6/27 NetOpsCoding#3 31
- 32. ネットワークアラート監視ツール 回答まとめ • 70%以上がSyslog+メール • 57%が不満/やや不満 • 望まれている機能 – 設定が容易 – ベンダー機種依存なく利用可能 – 通知回数を絞る (通知が埋もれないように) 2016/6/27 NetOpsCoding#3 32
- 33. Q. ネットワーク装置の コンフィグレーション作成 および 作業手順書作成への質問 • どんなツール/手段を使っていますか？ • 満足度を教えて下さい • 満足している点/不満に感じている点 を教えて下さい • 今後使ってみたいツールがあれば教え て下さい 2016/6/27 NetOpsCoding#3 33
- 34. コンフィグレーション作成および 作業手順書作成において、 利用している手段/ツール 2016/6/27 NetOpsCoding#3 34 参考 テンプレートエンジン : Network Engineer のためのTemplate Engine活用術 http://qiita.com/taijijiji/items/3d9d113c056a4488c32e
- 36. • 「テキストエディタを使った作成」に満足している点 – 特定のツールに依存しないこと – 手軽、簡単、環境を選ばない – 作成時が手軽 – 簡単に残せる – グーグルドライブとか、redmineとか何処にでも置くことがで きる – 作業の内容によって確認項目などを細かく決められる – 実際のconfigを読み名がら手順書を作っていくため、作成 中に適切でない既存NWの構成を発見できたりする（トラブ ルに成る前に気づける） 2016/6/27 NetOpsCoding#3 36
- 37. • 「テキストエディタを使った作成」に不満を感じている点 – 作成時にミスすることがある。 – （最近作業にはあまりかかわりませんが）打ち間違いやすい、手や目が疲れる – とにかくミスが発生しやすい – 定型作業だからといってコピペしまくると、置換忘れとか結構ある – 書き間違い/ミス/漏れの防止ができない – 置換漏れ – 似たような作業はコピペして、異なる点だけ置換していく→置換し忘れが多い – データの使い回しをしがちで、過去の設定を一部重複して入れてしまったり、同 じタイプの別機器に設定を入れてしまったりというミスを起こすリスクが高い。 – 作成に時間がかかりすぎる – バージョン管理、差分管理、定型作業のたびに手順書を作らないといけない – 人によってテキストエディタの文字コードが異なって憤慨 – 他社によるレビューがやりづらい (ポイントがわかりづらい) – 可塑性が低い – クラシカルだなぁと思う 2016/6/27 NetOpsCoding#3 37
- 38. • 「Excel + マクロ」に満足している点 – 手順の入れ替え（行の入れ替え）が容易 – 複数展開が楽 • 「Excel + マクロ」に不満を感じている点 – 個人開発のためバージョン管理がうまくいかない。また各種データが各 エクセルファイル内に記載されているため、鮮度や連携に問題がある。 – NW機器OSのバージョンアップ等でConfigが変更された際のメンテナン スに稼働がかかる – (特に上の人が)手順の見た目に拘ってくる。。。 – Visual Basicが嫌い 2016/6/27 NetOpsCoding#3 38
- 39. • 「テンプレートエンジンを使った自作ツール」に満足している点 – 同じようなコンフィグや手順書の作成が捗るようになった。既存のパラメータを抽 出して埋め込むなど、作り込み次第で手順書作成が楽になる – 基本テキストファイルのみなので、バージョン管理(+ チームでブラッシュアップ)が しやすい – 単純で汎用的なので、全く違う環境や定型作業でも、同じ仕組みを流用しやすい – あと、LLDP ベースで初期 config のパラメータを動的生成できる方式の ZTP は 大変良い (初期設定限定で、非標準を許容できない問題はあり) • 「テンプレートエンジンを使った自作ツール」に不満を感じている点 – 作りこむのが大変。同じような作業でも、微妙に設定や順序、範囲が異 なっているため、考慮して作りこむのが大変 – 非定型な作業には対応できない (ツールで定義されている内容に似て いるけど、実は適用できないやや非定型…というのが最も厄介かも。利 用者が、使えないのにツールを使って間違えた設定を生成して使ってしま ったり。) – 環境が必要。機器によっては難しい 2016/6/27 NetOpsCoding#3 39
- 40. コンフィグレーション作成/手順書作成において 今後使ってみたいツール その１ • GitHub • ansible は使ったことがある • DeviceExpert • Brocade Workflow Composer (Interop で眺めた感じ、まだ 形になっていない感じはするが、夢広がる感じ) • 必要なパラメータだけ与えたらScriptと手順書が自動で生成 されるツール • 特殊作業時にちょっと変更できる余地を残してくれているツール • 作業承認用の申請も一緒にやってくれるツール • 作成した手順書/コンフィグを自動で簡易テストしてくれるツール • 自動でコンフィグ作ってくれるツール • そもそも人による作業をやめたい 2016/6/27 NetOpsCoding#3 40
- 41. コンフィグレーション作成/手順書作成において 今後使ってみたいツール その2 • 最近Peeringのコンフィグについては専用GUIを作り、コンフィグ生成を半 自動で行っている(自動投入は理解が得られない...) • 大量に同様または似たコンフィグが必要なときは、Pythonやshellで生成 • 「手順 2 で状態が XXX なら OOO」みたいな手動実行や都度使い捨て スクリプトでやるなら簡単に出来るやつを、どうにか汎用的に定義できる ように… • 内容を入力したり、データを食わせてやったりすることで、一定の書式（ 表紙・スケジュール・工事番号・作業体制・作業項目・作業内容・投入 config・検印欄）をうまく整えて出力してくれるツール。上長検印用・作業 後のエビデンスとしての保管用途を想定。 • 現状、エクセルで雛形にこつこつ入力している。エクセルからターミナル ソフトへのconfigコピーペーストがやりにくいのでその点も改善できること が望ましい。 • RESTインターフェースでも何でも良いので、各社共通の標準化仕様が 欲しい 2016/6/27 NetOpsCoding#3 41
- 42. コンフィグレーション作成および 作業手順書作成 回答まとめ • テキスト/Excelを利用した場合は 70%程度が不満/やや不満 • 自作ツールを導入しているケースが多い • 望まれている機能 – 人為ミスの排除 (コピペミス/置換漏れ) – 大量コンフィグの自動生成 2016/6/27 NetOpsCoding#3 42
- 43. Q. ネットワーク装置の設定作業 への質問 • どんなツールを使っていますか？ • 満足度を教えて下さい • 満足している点/不満に感じている点 を教えて下さい • 今後使ってみたいツールがあれば教え て下さい 2016/6/27 NetOpsCoding#3 43
- 46. • 「メーカ標準のコマンドラインによる手動入力」 に満足している点 – どこでも・誰でも設定できる(端末や個人スキルに依存しない) – 環境を選ばない – ネットワークを実際に理解する時には、自動じゃなくてCliのほうが良い かな。と思うくらいです。 – ミスに対して、人手で柔軟に対応できる – 慣れているから – 動くこと。これがなかったら終わり。 – 特になし。あえて言えばコマンドラインによる手動入力は定型にはまら ない設定をやむを得ず投入することが柔軟にできる。 – ヤバい時にも何とかなる、みたいな自信 – コマンドを入れる前に最後の確認を人間の目でできる 2016/6/27 NetOpsCoding#3 46
- 47. • 「メーカ標準のコマンドラインによる手動入力」 に不満を感じている点 – コマンドラインによる手動入力は入力ミスやコマンド行抜けのリスクが ある。 – とにかくスケールしない。機種ごと/オペレーションごとに個別の作業が 必要。 – 手動である点 – コピペの場合バッファ欠けがある所 – 人によってミスあり。 – 作業者によってレベルが様々。 – 職人以外触れない -> 職人がいつまでたっても楽にならない – Cはコンフィギュレーションモードの変更が面倒 – ベンダーによって設定方法が異なる – 自動化できてない。Netconfを使いたいが、メーカ依存な部分も多く使 えてない – ときどき、自動化したい。(たくさん、設定したいとき) – どうせならOSのシェルをよこせ、嫌ならAPI被せて完全に隠蔽しろよ。 2016/6/27 NetOpsCoding#3 47
- 48. • 「自作ツール(Telnet/SSH/NETCONF/APIすべて含む)」 に満足している点 – it works! – ツールを使った場合、作業時間が大幅に減るので、助かっ てます – まあ大抵のメーカが「自分のところの機器限定で楽にでき るライブラリ・API」とか出しているので… – ログ取得が可能 2016/6/27 NetOpsCoding#3 48
- 49. • 「自作ツール(Telnet/SSH/NETCONF/APIすべて含む)」 に不満を感じている点 その1 – 柔軟性がなく、少しでも定型から外れた設定については利 用できない。 – ちょっと何かが変わるとうまくいかなくなる – 対象機器のファームウェアバージョンが変わってコマンド文 法が変わったら改修が必要になる。 – 各作業ごとにツールをその都度作成・改良しているため、 種類も多く、管理が大変。またツールのコードを触れる人が ごく一部に限定されている。 – エラーへの対応や、ツールの実装ミスが怖い – システマチックな作業が難しい 2016/6/27 NetOpsCoding#3 49
- 50. • 「自作ツール(Telnet/SSH/NETCONF/APIすべて含む)」 に不満を感じている点 その2 – ツールを自作するが、周りにプログラムが書けるオペレーターが 少ないため、メンテナンスを自分一人でやるしかない – 稼働削減のためにツール作ったはずが、自分の稼働は余計に苦 しくなるみたいなのが起こる（ネットワークエンジニアだとしてもコ ードは書けるほうがいいと個人的には思ってる） – sysDescr で仕分けて、独自 API や NetConf や expect …って なるのが面倒臭すぎて…。それを共通化して一番低いレベルに 合わせると expect に落ち着くのがクソ – メーカーによっては、CLIでは叩けるがAPIでは提供されていない 物があったり、出力結果が機械可読でないAPIがあったりする – オーケストレータの類も、South は Openflow or Netconf くらい しか対応していないものが多く、その Netconf さえ機種やバージ ョンによって動かない問題があって… 2016/6/27 NetOpsCoding#3 50
- 51. ネットワーク装置の設定作業において 今後使ってみたいツール/欲しいツール • APIを統一してほしい • netconfか標準化されたREST • ツールというか、データ構造の標準化は無理だと割り切って、 何かしら標準的で各メーカが当然のように実装している API ができますように (Netconf か REST API くらいか) • Configを流し込んでCommit直前で止まるツール • showコマンドによる自動状態確認ツール • 自動化しやすいCLI（APIではなく） • Ansible • やはりDeviceExpert 2016/6/27 NetOpsCoding#3 51
- 52. ネットワーク装置の設定作業 回答まとめ • 自作ツールを導入しているケースが多い • 自作ツールは変化に弱く、 継続的なメンテナンスが必要 • 望まれている機能 – 人為ミスなく設定できる – 変更に耐えられる もしくはメンテナンスしやすい仕組みがある – メーカ横断で利用できるAPI 2016/6/27 NetOpsCoding#3 52
- 53. Q. ツール開発体制 への質問 • ツールの開発体制を教えて下さい • 進捗や成果物に対する感想を教えて下さい • 開発を上手く回すために実施したことやコツなどが あれば教えて下さい • 困っていること、問題に感じていることがあれば教 えて下さい 2016/6/27 NetOpsCoding#3 53
- 56. 開発を上手く回すために実施したことやコツ • 拡張可能な設計にしておく • 1人開発であるが、ツールのメンテナンスで苦労しないよう「 実装に至る理由」を明記し、ある程度コーディングルールを 設けて机上デバッグでもアウトプットを予想しやすくしている。 • 運用チームで、運用専任week, 開発専任weekを作って、そ れをローテーションで回すようにしてました。（障害がなければ ）集中して開発できてたので、成果物もそれなりに増えました。 • 1週間毎に運用/開発を交代した →はじめは良かったが、 運用側が忙しくなりすぎると成立しなくなってしまった。 • 必要なときに、えいやで作る • 上司を説得して十分な開発環境を準備すること 2016/6/27 NetOpsCoding#3 56
- 57. 開発体制について 困っていること、問題に感じていること その1 • 人事異動に伴うメンテノウハウの継承。 • 引き継ぎ先が居ないこと • 教育研究機関なので、学生の研究テーマにしたいが、取り組む学生がい ないため、自身で開発するしかない。 • 開発というか魔改造すると、わかってないひとをさらにわからなくしてし まう。結局、自分が不幸になる。 • 運用/設計等が忙しくなるとコードに手をつけてられなくなる • 片手間でやっているので、いかんせん進捗が… • 大規模な作業や、障害があると、開発に取れる時間が数ヶ月単位でなく なってしまうのが困ってます • 運用環境は変化が多い（ファームウェアバージョンアップ・脆弱性対応ワ ークアラウンド設定追加・設定方針修正など）が、ツール開発を外注して いると半年・年単位で改修に時間がかかる。その場合、手作業でカバー する必要が出て、手作業設定に特有の人間的ミス発生のリスクが生じる 。サービス仕様が徹底されていないため、イレギュラーなオーダへの対応 が必要となった場合も同様。 2016/6/27 NetOpsCoding#3 57
- 58. 開発体制について 困っていること、問題に感じていること その2 • 監視項目の仕様をお客様と調整するにあたり、お客様とのコミュニケーションに 問題を感じている。重要度と優先度の一致を見るまで、投げたボールがなかな か返ってこない・・・。 • テストの知識に乏しく、テストが行いにくい • ちょっとしたスクリプト言語さえ書けない NW 屋さんが多くて… • コードを読める人が周りにいない • 周囲（他チーム）からの理解を得にくい • 温度差(意識的な問題/技術的な問題両方)意識的な問題で言えば、コピペ/繰 り返し作業が全く苦にならない人と層でない人の温度差。技術的な問題で言 えば、インフラからフロントエンドアプリまでの技術の幅をどう埋めるかという話。 • 言語宗派が… (同じものを別言語で実装しなおして、メンバごとに違うツール使 っていたり) • GitHubを使いたいが社内セキュリティがうるさくて使えない 2016/6/27 NetOpsCoding#3 58
- 59. 開発体制の 回答まとめ • 一人で開発する場合は80%が上手くい っていない – 社内で仲間を探すことが近道か • 運用チームが開発する場合は、 継続的な稼働の確保が課題 • 下記のような流れが理想的？ 一人で開発 -> 運用チームで開発 -> 開発チームを立ち上げて開発 2016/6/27 NetOpsCoding#3 59
- 60. Q. その他の質問 • ネットワーク運用業務にOSSを利用することについ ての印象や実態を教えて下さい。 • 今後作りたいツールや、欲しいツールがあれば教え て下さい。 2016/6/27 NetOpsCoding#3 60
- 62. 今後作りたいツールや欲しいツール • Cisco 機器を対象とした場合 show コマンドを実行しないと取得できな い機器稼動データ(値)がありますが、そのデータを定期的に取得し、可 視化や統計処理しやすい形で提示してくれるツール。show コマンドの実 行結果をjson形式でも取得できるような状況にならないと難しいかもし れませんが。 • ネットワークの受け入れテスト。機材のリプレースやOSの更新、パッチ宛 てなどで、システムやサービス全体がどう影響があるのか、見たいな話を 主導でテストするのがツライ。ネットワークの通信要件定義や実際こうい う振る舞いをしてほしい、という私用定義を元に、end-to-endの通信ベ ースでテストをしていくようなツール。検討/一部開発中。 • 構成管理自動->Script自動生成->Script流し込みが連結したツール • ルータ/ネットワーク全体ののヘルスチェックができるWEB • 先方に情報を入力してもらうと、自動でBGP設定を投入してくれるツール 2016/6/27 NetOpsCoding#3 62
- 64. まとめ • トラフィック監視 – ニーズはあるものの、現状の不満は少なめ • アラート監視 – 山のような通知メールから脱却したい • 手順書作成 – 人手によるミスから脱却したい • ネットワーク装置設定 – 自動ツールは作って終わり、ではない – API統一が待ち望まれている • 開発体制 – 一人はうまくいってない – 運用チームで開発するには、稼働確保が課題 2016/6/27 NetOpsCoding#3 64
- 67. 理想的なDevOps体制をつくるために 2016/6/27 NetOpsCoding#3 67 一人で開発 運用チームとして 開発 開発チームとして 開発 このあたりをNetOpsCodingで サポートし合いたい • 導入事例の共有 • ノウハウの共有 • 使ってみた • 作ってみた
- 69. Tipsまとめてみた （絶賛編集中） https://github.com/netops-coding/netops-tips/wiki 2016/6/27 NetOpsCoding#3 69 編集を手伝ってくれる方 募集中！
- 70. Slackつくってみた • netopscoding.slack.com • 参加したい方は、下記情報をご連絡ください – 宛先: netopscoding@googlegroups.com – 登録希望メールアドレス – First Name / Last Name 2016/6/27 NetOpsCoding#3 70