IT 自動化から始める DX！まずは運用業務を Ansible に引き継ぎ

DX を進める前に直面する課題

さぁ！DX！と進めようとすると以下の課題に直面されている方が多いのではないでしょうか。

• 学習コストがかかる
• 人材不足
• とにかく今ある業務が忙しいから手を出せない
• そもそもどこから取り組めば良いのか分からない

ただでさえ忙しいIT業界。これらの課題に対して、どう対処していけば良いのでしょうか。

まずは、短期間で一気に進めようとするものではなく、焦らず長期的な目で検討していくことが

大切なのだと思います。
まずは小さいところから、段階的に大きくしていくことを考えて頂ければと思います。

それでは何から始めるのか？

そこで！！まずは IT 自動化への取り組みを検討してみませんか？
今回は IT 自動化の良さをメインにお伝えできればと思います。

IT 自動化とは・・・

こちらのキーワードもよく耳にされていると思います。

当ブログにおきましては、 IT 自動化は「日々の IT 運用業務を、人ではなく自動化ツールに引き継ぐこと」

であるとさせていただきます。
例えば、以下のような作業が該当するかと思います。

• サーバリソースの払い出し
• 各種サーバ、ネットワーク機器の設定変更　などなど

上記のような業務を手作業で実施することにより、エンジニアの工数がかかるのはもちろんのこと、

ヒューマンエラーを引き起こすリスクも伴います。
ヒューマンエラーが発生してしまうと、通常業務の作業工数に障害調査、および復旧作業時間等もプラスされ、どんどん稼働が増えてしまいます。
IT 自動化はこのような稼働時間を削減することが可能となります。

その結果、今まで運用業務で使っていた稼働時間を以下のような業務に割り当てられるように

なるのではないでしょうか。

• DX 推進に向けたコンテナの学習時間
• DX 推進プロジェクト計画

IT 自動化するためにはどんなツールを使えば良いのか

IT 自動化ツールには様々なものがあります。

• Chef
• Puppet
• Ansible

上記ツール群の比較は様々な技術ブログ等で紹介されていますが、
やはり Ansible がだんとつ使いやすいと言えるでしょう。

Chef や Puppet の場合、各クライアントサーバにエージェントをインストールしたり、
構成を管理するためにプログラミング技術が必要になります。
それに対して Ansible は以下の点が挙げられます。

• 管理サーバから SSH 接続さえできれば、クライアントにエージェントは不要
• 構成を管理するための言語は、読みやすく・書きやすく・分かりやすいYAMLを使用。

要するに、「 Ansible は管理しやすい=属人化しにくい」ということを意味するのだと思います。
運用担当者が一人に偏ってしまうようでは、企業にとってベストな体制とは言えません。
万が一、担当者の一人が体調不良でお休みしてしまった場合でも、チーム内の誰もがシステムを管理、

運用できる形が理想だと思いませんか？

Ansible って本当に管理しやすいの？

ここで、Ansible にてクライアントを構成するための Playbook の内容を少しだけ紹介します。

Playbook は yaml 形式にて作成します。

例えば、運用チームに新しく tanaka さんという方が配属になったとしましょう。
その時に、運用チームで管理しているサーバーは 20 台あるとします。

すべてのサーバーにログインし、useradd コマンドを実行して tanaka さんを追加するという作業は、漏れやミスが出てくるかもしれません。
こういう時に Ansible に任せてみましょう。

以下のような Playbook を作成します。

上記は一番簡単な例ではありますが、Linux におけるユーザー追加の定義さえ理解していれば、

一般的なプログラミング言語に比べるととても分かりやすい構文になっている事が分かります。

上記の Playbook を ansible-playbook コマンドにて実行するだけで、20台のサーバーに対して、
一斉にユーザーを追加してくれるのです。
これだけでも手作業での工数がだいぶ削減されますよね。

設計書、作業手順書の代わりに Ansible Playbook を利用

これまで紹介しました通り、Playbook は非常に分かりやすい構成となっていますので、

設計書、作業手順書の代わりに Ansible Playbook のみで構成を管理されているケースも少なくありません。

時間をかけて設計書、作業手順書を作成しても、結局は人間が手を動かす形で作業を実施する必要があります。

それに対して、Ansible では Playbook さえ作成しておけば、コマンド1つで記述された内容の通りに

クライアント環境を構成してくれます。

人に引き継ぐためのドキュメントを作成する代わりに、Ansible にお仕事を引き継いでみることを

是非ご検討ください。

最後に

Ansible の魅力を少しでも感じて頂けましたでしょうか。

今ある運用業務の中で、これだったら Ansible に引き継ぎができそうと思われるタスクがありましたら、

ぜひ一度 Ansible を使ってみてください。

実はこの Ansible、まだまだ魅力が詰まっているツールです。

これからも SIOS コンテナの窓口を通して、引き続き Ansible の魅力をお伝えしていきたいと思います。

コンテナの窓口では、過去にも Ansible についてご紹介している記事がありますので、
こちらもぜひご一読ください。

リモートワークが出来る理由、出来ない理由 Vol.2 〜 Ansibleを活用したリモート対応運用

なぜ進まない！？企業の自動化の課題と進め方

最後までご覧いただき、ありがとうございました。