ITインフラ 業務自動化現状確認会を催しました #infra_auto

ITインフラ 業務自動化現状確認会を催しました #infra_auto

昨日、「ITインフラ 業務自動化現状確認会」という勉強会を催しました。前々からゼミナール形式の勉強会を開いてみたいと思っていまして、ちょうど @kuwa_tw さんとある話をしているときに流れで「一緒にやりましょう!」と話しかけた事で実現しました。

人が集まるか心配したのですが、ふたを開けてみれば自動化に造詣が深い10人の方にお集まりいただきました。Togetter「ITインフラ 業務自動化現状確認会 (2014.10) #infra_auto」に模様もまとめています。

僕の発表内容

社内向けに開発した”hb-agent”という構築自動化・ドキュメント自動生成ツールについて紹介しました。

勤務先のハートビーツはMSPとして、お客様のサーバを預かり、構築・運用・障害対応・チューニングを一手に引き受けています。その中で、これまで培ってきたノウハウがたくさん存在します。一方、IaaSをはじめとして大量のサーバが即座に構築できる時代になり、かつ自動化が進展しています。そんな中、自社サービスとはちがい、たくさんいらっしゃるお客様それぞれ違った環境がある中で、どのような形で自動化すれば良いのか、自分たちで模索する必要がありました。今回は、その経緯についてお話ししました。

話している中で皆さんに刺さったのが、こういったツールを社内に普及させるために半年程度で完了した、という点でした。良い技術、良いツールを準備しても普及させるのが大変である事は、各地で聞かれます。そんな中で普及できたのは、次の点があったからだと考えています。

  1. 社内勉強会での宣伝
  2. ハンズオン会の開催
  3. CTOを初めとした上層部の後押し

1は、まずは「存在を知ってもらう」事を目的としてやりました。興味がある人を見つけて、まずは同志を作る事ができます。

2は、今考えると最も大切なプロセスだったのだろうと思います。数人を会議室に集めて、ハンズオンを行います。当然、全員集まらないので、何回も(確か5回はやった)行います。その上で、「触って」「感動して」そして「理解」してもらう事で普及を進めます。触る事で何者かがわかりますし、今までと変わる部分をきちんと体験してもらう事で良さを伝えようとしていました。そして、良いと思ってもらえれば、自然と使ってもらえます。

3は、CTOの @netmarkjp さんの「プログラム開発を通じてITインフラ 構築・運用業務を効率化するぞ!」という強い意志のもと、自動化を後押しをしていただけたのはとても大きかったのです。大方針を上層部の方たちと共有でき、その上でリーダーシップを発揮していただけるほど、やりやすいものはありません。

あと、ひらしーさんからドキュメント自動生成部分は公開されないの?という話を頂きました。時間を作って、ちょっとがんばってみようかなと思います。

なお、今回紹介したのは、自動化を進めている事の一部です。他の話は、また機会があれば現状確認の題材にします。

感想

ITインフラの自動化、本当に進展が早いですよね。「Automation Tech Casual Talks #1」という勉強会が2012年にありましたが、その頃とはだいぶ変わりました。1年前ともまた違いますよね。

さて、今回は名だたるWebサービス企業やITインフラを支える会社にお勤めの方が来ていて、とても濃厚な時間でした。そんな中で、話を聞いていて次の点が印象に残りました。

  1. 業務内容によって自動化の方針が大きく違う
  2. 規模と自動化の進展状況により悩みが違う
  3. ツールを調べる・作る力が自動化をより楽にする

iは、特に自社サービス・受託で自動化の方針が大きく違う事がわかりました。自社サービスですと、開発した製品に沿って完成度の高い自動化を進めます。一方で、似て非なるものが出来上がってしまう事があり、その整理に心血を注がねばならない悩みがある事がわかりました。受託ですと、お預かりしたお客様毎に状況が違うなかで、共通した秘伝のタレや結果をベースに最大公約数を見つける必要があります。非常に大変な作業なのですが、これができるとどのようなお客様に対しても、より素早くかつ人によってばらつきが少ない品質のサービスを提供する事ができるようになります。非常に面白い話でした。

iiは、大規模な場合、小規模がたくさんある場合とでまた悩みが変わってくることがわかりました。 例えば tnmt さんの話ではありませんが、皆さんの会社ではどのようなホスト・ロール管理をされていますか?その必要は無い規模?でもその環境って再構築できます?ふむふむ…と色々出ますね。

iiiは、ひらしーさんのように serverspec-runner というプロダクトを作り、B2Bだとよくあるテスト項目書の生成を自動化する事でみんなを幸せにできる人がいます。また、れいさんのように最新の技術をキャッチアップし、より自動化を楽にする事でみんなを幸せにできる人がいます。その中で、自分は何に貢献することが良いのか?は自問自答し続け行動する必要があると、覚悟を新たにしました。

まとめますと、ITインフラ、特にこの日参加した自動化を担当する人たちは、自分の所属する組織の状況を俯瞰し、その中で最も効果がある点に手を入れる事で、組織に貢献している事がわかりました。このような優れた視点と技術を持っている人たちと情報交換をする機会に恵まれ、僕自身とても幸せな時間を過ごす事ができました。

皆さんの発表内容

いつものノートです。オフレコ部分は省いています。

@noexpect さん

  • Jira を用いた大組織におけるノウハウ共有の方法についてのお話

  • ※公開するか判断に迷ったので一旦オフレコにしておきます

@rrreeeyyy さん

スライド: Itamae 使ってみた

  • Provisioning Toolの話

  • Ansible + Serverspec
    • Python + Ruby
    • いろいろ覚えないといけない
    • れいさん的には気持ち悪いとのこと (確かにそうだ)
  • Itamae
    • 先日の Infrastucture as Code 現状確認会 で発表された
    • よいところ
      • Agent Less
      • Simple
      • Ruby DSL Like a Chef (互換性は無い)
      • Specinfraの上で成立している
      • gemでレシピが管理できる(Berkshelfいらない)
  • dry-runいい感じ!
    • diffも映っていい感じ (あれChefでも出なかったっけ)
  • 設定も集約させやすそう
    • 変更も他の設定に波及させやすい
  • ディレクトリ構造
    • provision
      • レシピ
      • いらない場合はInclude Recipesを削除するだけで事足りる
    • spec
      • Serverspecのテストコード
  • デモよかった!
    • レシピ公開が期待される

@oko_chang さん

スライド: 発表資料

  • Cloud Automator のインフラ+開発担当

  • 開発
    • Rails
    • AWS SDK for Ruby
    • AWS Flow Framework (AWS Simple workflowを動かすために使う)
  • 監視サービスは持たず、全部Cloud Watchに集約。
    • 通知もSNSから。
  • SaaSは積極的に使う
    • 人が少ない
    • HipChat連携してる
    • Errbitを使ってエラーもとりまとめている
  • メンバー なんと5人
    • 仕事は兼任
    • 自動化をして開発時間を捻出
  • OpsWorks
    • Load Averageベース・時間スケール(Job集中を見積)でAuto Scaling
    • Auto Healing – インスタンス障害への対処
  • Itamae, serverspec 積極導入中

  • EC2再起動祭り
    • これにも対処しやすかった
  • 問題
    • Web上の設定が見える化できない
  • まとめ
    • 効率化して開発にリソースを割く
    • 設定内容の見える化
  • 議論
    • North Californiaにあるのは?: DRが主目的 マルチリージョンでできるように
    • OpsWorks インスタンス枯渇問題
      • 日本だと起きやすい
      • 足らない問題が出やすいインスタンスは避ける t2系とか
      • 最終的にはSpot Instanceを使う

@koemu

  • 自分自身: 前述の通り

@y05_net さん

スライド: インフラ構築とテストについて

  • serverspec-runner

  • serverspecのテストコードをそのまま利用する
    • テスト結果がテキスト(テキスト表、Markdown, CSV)に出せる!
    • 納品ドキュメントがすぐ作れる!
    • 最高だ!!!

@kuwa_tw さん

スライド: Chef環境の闇

  • 統合Chef Cookbookリポジトリの問題
    • 集約しよう!となるよね普通
    • はまりポイント
    • 依存度高い問題
      • リポジトリの間の依存度が高い
      • yumぐちゃぐちゃ どこ見てるの?
      • 整理した
    • 名前かぶり問題
      • apache, nginx めっちゃあるで
      • Community Cookbook使えない
      • Chefサーバやめない?
      • Renameで対応
      • 今後はCommunity Cookbookにしたい
        • しかし今度はどれ使うの?
        • ★の数?
  • 最初の設計間違えない!
    • (とはいえ、初期の頃はベストプラクティスも無かったから色々頭が痛い。)
  • Community Cookbook どう使うのか問題

  • 集約は無理にしなくても良いと思う

  • Chef-solo + Berkshelf 移行で幸せになれました

  • Chef-serverはサーバ管理に直結しないと使いづらい

@hokkai7go さん

スライド: なし

  • 前の会社の知見が本に活きた!とのこと。

  • Cookbook CI
    • やりすぎなのでは!?
    • 成果物をみるのが正しいアプローチだよね
      • Serverspec
    • コードの見通しも必要だが
    • テストのやり方は決まってない感ある
    • 全部の設定はみられない
    • 全体がちゃんと動く所まで確認できないのがわからん、どうすりゃいいんだ!
  • 自動化に至る軌跡
    • 受託・自社サービス それぞれ違う
    • どんなステップを踏んでどうするのか
    • そこを突き詰めて行きたい

@tnmt さん

  • 資料を作ったモティベーションをはなします

  • 10分デモし倒します!
    • Puppet
  • ホスト管理
    • みんなどうやって管理してる?
    • ホスト名の命名ルール
    • インベントリ収集ツールの結果
    • Zabbixの情報 → 監視しているサーバは存在すると決める
  • インベントリ管理サーバ パワーアップ

  • 議論
    • Consul
      • サーバ一覧出せるよね
      • DNSとも連携できるよね

@buty4649 さん

発表メモ: 発表資料

  • Hubot

  • デモンストレーション!

  • ChatOps事例
    • muninのリンクを返す
    • nagiosのリンクを返す
    • httpingする
    • テストメール送信
    • リマインダー
    • 自動デプロイ
      • CapのWrapperを叩いている
  • 議論
    • Hubotがいいところ
      • 流行っている
      • mentionのハンドリングとかは楽
      • 他のチャットエンジンと切り替えやすい
    • CoffeeScriptの辛み → 非同期パターン

@OmochiStrike さん

  • オフレコ話

おわりに

「理想の勉強会」とは何でしょうか。僕は、ゼミナール形式で知見を交換し、議論しあう場だと思っています。今回、こうして自分自身が参加してみたい勉強会を催せた事を本当に嬉しく思っています。仕事、家庭、個人、色々ある中ではありますが、またゼミ形式で現状確認会を開催したいと考えています。3ヶ月も経てばまた時代は動いているでしょう。その節はよろしくお願いします。

最後に。呼びかけに応じていただいた @kuwa_tw さん、懇親会会場をセットアップしてくれた @rrreeeyyy さん、そして誘導やセッティングを支援いただいた @ttkzw さん、どうもありがとうございました!

LINEで送る
Pocket