株式会社TKC 様

• 課題①：お客様先ネットワーク機器の設定変更作業は、現地に訪問する必要があったこと。
• 課題②：お客様先ネットワーク機器の設定変更作業では、ミスが許されず、かつ作業内容は客観的な妥当性を証明する必要があること。
• 課題③：最新のコンフィグ、およびコンフィグの変更履歴の管理方法に統一性が無かったこと。

2015年4月

• 効 果1　コンフィグの確認や変更、調査用のログ取得を、リモートから実施可能としたこと。コロナ禍において 顧客訪問が困難な中、リモートから対応できるようになった。顧客に感染させないだけでなく、当社社員の 感染リスクも低減することができた。
• 効 果2　誰が・いつ・何をしたか、証跡管理が可能になったこと。作業ミスが無かったことを立証しつつ、 トラブル対応にあたることができるようになった。
• 効 果3　ＡＰＩにより、ユーザー個々のネットワーク環境に応じたコンフィグをカスタマイズして設定できるよう になったこと。プログラムによるコンフィグの生成から投入・設定反映までの一連を機械化することで、 作業ミスや作業漏れを排除することができるようになった。
• 効 果4　コンフィグの履歴管理が自動的にできるようになったこと。問題発生時の差分比較や過去のコンフィグの 復元が容易になり、また保守会社と連携することで当社ＳＥが現地訪問せずとも、保守会社が ネットワークを入れ替えてすぐに直前まで使用していたコンフィグを投入できるようになった。

当初はAnsibleで運用環境を構築しようとしましたが、弊社で採用している富士通社製ネットワーク機器はPlaybookの提供がありませんでした。お客様ごとに設定内容の異なる9,000台超のルーターをソフトウェア的に管理するにあたり、コンフィグの 生成からPlaybookの作成まで自社で構築するのは困難でした。API経由でNetLDの操作ができることで、コンフィグ生成部分の開発に注力できるようになったため、運用コストが非常に下がりました。

ＡＰＩ
■理由：NetLD単独では不足する機能について、当初はAnsibleで自動化することを検討していた。 NetLDにAPIが搭載されていることを知り、それを自製のプログラムと組み合わせることにより、自組織に完全にマッチした状態で運用できる環境を構築できた。従って、Ansibleは不要となった。

• 追加希望の機能：取得したコンフィグを解釈して、投入するコンフィグを生成するマクロ機能
• 追加希望の機能：パスワードの管理、更新機能（現状、機器のログインパスワードはクレデンシャルへの登録の他、EXCEL で管理する必要があり、それ自体の漏えいを危惧する。NLD１か所でパスワード管理し、 コンソール接続など必要時にはNLDからパスワードを確認できる仕組みが望ましい）