[win_2016]
192.168.10.233

[win_2012]
192.168.10.248

[windows:children]
win_2016
win_2012

[windows:vars]
ansible_user=Administrator
ansible_password=P@ssw0rd
ansible_connection=winrm
ansible_winrm_transport=basic
ansible_winrm_server_cert_validation=ignore

実際には、最後の1行(cert_validation)は後から付け足しました。

この手順通りに実行した場合、操作対象のWindowsには自己証明書が導入されるのですが、そのままだと接続のときに証明書の確認エラーで弾かれてしまいました。（以下ログ）

Gathering Facts...
  192.168.10.233 unreachable: {
    "changed": false, 
    "msg": "basic: HTTPSConnectionPool(host='192.168.10.233', port=5986): Max retries exceeded with url: /wsman (Caused by SSLError(SSLError(1, u'[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:618)'),))", 
    "unreachable": true
}

そのため、もう一度公式ガイドを確認したら、cert_validationについて、しっかり書いてありました。ちゃんと読め自分。

Windows側

インストール時のパラメータ

基本的に、Administratorのパスワードをインベントリに合わせたくらいです。

WinRMの設定

公式ガイドに、PowerShellでセットアップできる方法が記載があったため、そのまま実施。

Windows PowerShell
Copyright (C) 2016 Microsoft Corporation. All rights reserved.

PS C:\Users\Administrator>
PS C:\Users\Administrator> $url = "https://raw.githubusercontent.com/ansible/ansible/devel/examples/scripts/ConfigureRemotingForAnsible.ps1"
PS C:\Users\Administrator> $file = "$env:temp\ConfigureRemotingForAnsible.ps1"
PS C:\Users\Administrator>
PS C:\Users\Administrator> (New-Object -TypeName System.Net.WebClient).DownloadFile($url, $file)



PS C:\Users\Administrator> powershell.exe -ExecutionPolicy ByPass -File $file
Self-signed SSL certificate generated; thumbprint: 804F14E0FFED613185E8049AEF5AB79E578DC775


wxf                 : http://schemas.xmlsoap.org/ws/2004/09/transfer
a                   : http://schemas.xmlsoap.org/ws/2004/08/addressing
w                   : http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
lang                : ja-JP
Address             : http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
ReferenceParameters : ReferenceParameters

OK

設定されているかどうかの確認

こちらも、公式ガイドにあったとおりのコマンドでListenerの状態を確認。(ログはWin2016側のもの)

PS C:\Users\Administrator> winrm enumerate winrm/config/Listener
Listener
    Address = *
    Transport = HTTP
    Port = 5985
    Hostname
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint
    ListeningOn = 127.0.0.1, 192.168.10.233, ::1, 2001:0:348b:fb58:28d8:154a:3f57:f516, fe80::28d8:154a:3f57:f516%4, fe8
0::e572:d2e2:836a:bafe%3

Listener
    Address = *
    Transport = HTTPS
    Port = 5986
    Hostname = WIN-KPFBQSB4964
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint = 804F14E0FFED613185E8049AEF5AB79E578DC775
    ListeningOn = 127.0.0.1, 192.168.10.233, ::1, 2001:0:348b:fb58:28d8:154a:3f57:f516, fe80::28d8:154a:3f57:f516%4, fe8
0::e572:d2e2:836a:bafe%3

よくあるハマりで、Windows Firewallの設定があるなあと思ってそちらも確認してみたのですが、自動で接続許可設定が入っていました。(Win2016/Win2012いずれも)

行き届いている…

またPowerShellの中身そのものは確認しておきたいところです。

両方完了後の疎通試験

win_pingモジュールを使いました。

もくもく会では、sshでの疎通試験だったなあと思いつつ、WinRMではどうやってやるんだ？と思い、Windowsのモジュール一覧を確認していたら、win_pingなるものがあるのを見つけました。

モジュール一覧から、目的のもの見つけ出すのは楽しいですね。

win_ping.yaml

---
- name: Windows WinRM Ansible
  hosts: windows
  gather_facts: no

  tasks:
    - name: ping
      win_ping:

実行結果

ping...
  192.168.10.233 ok
  192.168.10.248 ok

Windows Updateの実施

まだやってる最中ですが、Win2012/Win2016いずれも1回は成功しました。

こんな感じのPlaybookにしています。

---
- name: Windows WinRM Ansible
  hosts: windows
    - name: Do Windows Update 
      win_updates:
        category_names:
        - CriticalUpdates
        - SecurityUpdates
        - UpdateRollups
        state: installed
#        reboot: yes
#        reboot_timeout: 1800
      register: update_result

    - name: debug
      debug: 
        var: update_result
        verbosity: 0

    - name: reboot if needed
      win_reboot:
      when: update_result.reboot_required

最初はwin_updatesの中でリブートという流れにしていたんですが、初回Update後のリブート→再起動後のパッチ適用でreboot_timeoutの初期値1200秒を超えてしまい、最終結果がfailedになることがわかりました。 Timeout値を長くしようか悩んだ挙句、まずは結果の出力を優先し、アップデートを切り離すことに。

やってみて

とっかかりこそ苦労したものの、2台目のホスト（Windows2012 R2)のセットアップはとても簡単でした。

今まで業務でPoC環境作るのに手動でぽちぽちやってたのがウソみたいです。

まずは取り急ぎ動かしてみただけなので、実運用を考えた場合に修正すべき点はたくさんあると思いますが、便利さが実感できただけでもとても満足できました。

今後もこんな風に、小さな成功体験を積み上げていきたいと思います。

ただ、動かしている最中に、どの程度作業が進行しているのかがわからないのが、ドキドキしてしまいます。（％表示とかが出ないので）

この辺は何かうまい方法があるのか、また探してみたいなと思います。

追伸

(現在、Win2012の2回目で絶賛ハマり中です…)

Do Windows Update...
  192.168.10.248 failed: {
    "changed": false, 
    "filtered_updates": {}, 
    "msg": "Failed to search for updates: \"1\" 個の引数を指定して \"Search\" を呼び出し中に例外が発生しました: \"HRESULT からの例外:0x80072EFE\"", 
    "updates": {}
}

追伸の追伸

上記エラーは2回試して2回とも発生しました。

大型アップデートとかの初期処理がログイン後に走るのかな？と思ってコンソールでログインしてみましたが、特に動きはなく。

ただ、その後何もいじらずに再度WindowsaUpdateのPlaybook走らせてみたら、問題なく動きました。

ログインが功を奏したのか、時間が解決したのか、一体何なんだ…

またログなど確認して原因分かれば調べてみたいと思います。

2019-10-08

DO280(OCP Administration I)&EX280(認定試験)の受講記録

OpenShift

先日、DO280(OpenShift Container Platform Administration I)の教育を受講してきました。

また、その翌日にEX280(認定試験)も受験してきました。

その際の記録を残しておきます。

DO280とは？
参加日程
教育(DO280)の内容について
認定試験(EX280)について
動機はなんだったのか？

DO280とは？

Red Hatさんの2020年度の事業戦略の3本の柱の一柱、「クラウドネイティブなアプリケーション開発」の基盤となる、OpenShiftのプラットフォーム管理者向けの教育コースです。

詳細については以下URLをご参照ください。

Red Hat OpenShift Administration I (DO280)

参加日程

以下日程で参加をしてきました。地方からの参加＋翌日に同じ会場でEX280(認定資格試験)もあったので、3泊4日の出張となりました。

DO280 : 2019/9/24 - 9/26
EX280 : 2019/9/27

上記日程のうち、一番後ろの席の、左から三番目のおっさんが私です。

初日と最終日にカートを転がしてるのは自分くらいでした。
やはり、首都圏の受講者が多いのですね。

ちょうどニュースでRed Hatさんの親会社のIBMさんが自社ソフトウェアをOpenShiftに最適化～～というニュースが入ってきた時期だったこともあり、需要も増しているのかなと思いました。

教育(DO280)の内容について

OpenShiftの対象バージョンは3.9でした。

既に4.xがGAしていることや、メトリクスの標準が変わっていることもあり、少し前の内容という感じです。

基本的には、上記URLの「学習内容」に書いてある内容について、章ごとに以下の流れを繰り返す感じです。

講師の方からの概念論の説明
解説付きの実地演習
解説無しで問題文だけの実地演習

初日は問題なくついていくことができていたのですが、二日目の実地演習あたりから途端にスピードが上がり、解説無しの実地演習を1つ全くクリアできない状態でその日が終わってしまうという失態を演じてしまいました。

新鮮だったのが、「後の章で詳細に解説します」という内容がわからないと前の章の解説無し問題が解けないような状況が、普通に発生していたことです。
実際には、さわりの解説は実施していただいていたので解けないこともなかったのだと思うのですが、油断していて初日の復習をサボったせいもあり、二日目はとても大変でした…

後は、教材がすべて英語だったのも少しつらいところでした。これは時期にもよると思います。講義そのものは日本語でした。

普段から慣れている自分の得意分野の英語マニュアルと違い、概念から勉強する内容も多かったため、講義中は読み取れない点もあり、割とアワアワしていました。

ホテルに帰って、日本語翻訳されたマニュアルを食い入るように読んでいました。とてもありがたかったです。RedHatさん、翻訳本当にありがとうございます。

認定試験(EX280)について

出張期間の間、割と夜遅くまで必死に復習した結果、最終日の認定試験(EX280)はなんとか合格することができました。祝。点数はギリギリでしたが。

EX280合格してた！！！！
合格点210に対して217点でギリギリのラインだけど、復習しっかりしてよかった！！
— tatematsu_san (@tk4_jj) September 29, 2019

Red Hatさんの認定試験は初めて受験したのですが、完全実技形式で3時間があっという間に過ぎていきました。

認定試験の内容は守秘義務もあるので書けないのですが、私の勉強方法としては以下の通りです。

試験の学習ポイントに書かれている項目ごとに、DO280で学んだコマンド群を整理
よくわからなかったところは公式ドキュメントを見て解説を読む
前提となっているコンテナ関連の知識も理解が怪しいところがあったので、OCP以外の部分もググって調べる

DO280を受講されてからEX280を受験される方は、講師の方がおっしゃることを素直に受け止めてやってみる、ということが大事だと思います。

試験についての学習ポイントなどの詳細な情報は、以下URLをご参照ください。

Red Hat Certified Specialist in OpenShift Administration exam (EX280)

動機はなんだったのか？

実は、会社での立ち位置としては、私はOpenShiftに関連するプロジェクトは一切関わっていなかったりします。本当、なんで受けたのと思われても仕方ない感じですが。

今回教育受講をした主な動機は、実は間接的な理由だったりします。

OpenShiftを業務で扱っている同僚がいるのですが、割とぼっちというか、上司も含めて周りには開発者しかおらず、インフラ面でいろいろと会話ができるメンバーが近くに居ないという状況があります。その同僚とは部門を超えて仲が良かったりするので、社内でOpenShiftの会話出来るメンバーが他にいるといいだろうな、というのが動機だったりします。

チャレンジングな事をやっていても、後ろを振り返ると誰もいない状態はつらい、というのは自分もよく経験してきましたので、周回遅れだったとしても会話できるメンバーが一人でも近くに居れば、前に進むモチベーションも維持できるかなと思ったからです。

先日一緒に飲んだのですが、OpenShiftについて嬉々として話をしてくれて、受講・受験してよかったなと思いました。機会を作ってくれた皆様に大変感謝です。

後は、単純にエンタープライズでコンテナ周りを活用するにはどんなことを考える必要があるのだろう、というベースの知識をいい機会なので一気に身に着ける、という動機もありましたが、それもなんとか達成できました。

今後、何かの形でエンタープライズでコンテナを活用する場面にも関わっていって、身に着けた知識を直接的に仕事で活用したいと考えています。

DO380(クラスタリングとかまで含んだ高度な内容)は…ちょっと間接的な理由ではつらいかもですが、またチャンスがあれば…

2019-09-14

Ansibleもくもく会＠Softbank(A10編)に参加しました。

Ansible

2019/9/13(金)に開催された、Ansibleもくもく会に参加しました。

今回は、実業務でもかかわりのあるA10さんの機器が触れるとあって、とても楽しみにしていました。

今年の2月から初めて、通算6回目です。常連といっても過言ではない…？
いろいろな事情で、Ansibleちからは、ほとんど上がっておりませんが…！orz
来月から本気出す！

会場
コンテンツ
環境
やったこと(Y)
わかったこと(W)
つぎやること(T)
成果共有についての感想
全体的な感想

会場

普段のRedhatさん会場(目黒)ではなく、今回はソフトバンクさん(汐留)で開催！
以前、フェニックスプロジェクトの研修でお邪魔したビルと同じでした。
(とはいえ、ふだんからリモートばかりですが…)

コンテンツ

記憶だけでざっくりと書くとこんな感じの内容です。不足あったら申し訳ありません。
見ていただけるとわかりますが、とってもボリューミーな予感がしました。

VLANの作成
物理ポートへのVLAN割り当て、VEへのIPの付与
インターフェースのEnable
Serverの宣言
ServiceGroup/Port/VirtualServerの作成にあわせたIPの設定、バランシングアルゴリズムの設定
NATプールの作成
運用上必要となるServerのDisable/Enable
HTTPSの証明書のインポート→ClientSSLテンプレートへの展開→TCP443待ち受け

イメージとしては、A10さんの機器のスタンダードな使い方のハンズオントレーニングを、WebUI/CLIではなくAnsibleを使って実施する、という感じです。

詳細なコンテンツは、以下URLに掲載されています。これは永続で公開されるとのこと。大変ありがたいことです。

https://github.com/kishizuka4989/ansible_training_a10_thuner_adc/blob/master/README.ja.md

環境

環境面から普段とは大きく異なりました。

普段のもくもく会

SSH（接続先IPなどは一覧があるURLから探す。全環境に直接アクセス可能）
Towerをやる人はブラウザ
もくもく会での操作対象はAWS上

今回

Ravelloによる統合管理Webコンソール
SSH（接続先IPはRavello上に記載。直接アクセスは最低限で、A10へはWindows経由でSSH接続)
RDP（接続先がWindowsのため、Macユーザの方は苦労されたのでは…)
もくもく会での操作対象はGCP上(名言無し、IPから推測)

私のメイン端末はWindows Homeなので「RDPできないじゃないか」と思ってWindowsストアなどで互換アプリを探してテストしたりしました。
結局、RDPクライアントはWindows Homeでも普通に使えて、RDPの待ち受けができないだけだというひどい思い違いをしており、顔から火が出る思いです。ぐふう。

自身の操作環境のカイゼン(未遂)

Twitter上で「Visual Studio Code remote便利」というのを見かけていたのでプラグインの導入だけはしていたのですが、SSH接続方法がパッとわからず普段通りTeraTermでポチポチ…

ちゃんと後で学習しました。これマジで便利ですね。
むしろ、これまでTeraTerm+Vimで手打ちしてたのをあまり疑問に思わなかったアホの子でした…

vscode remote完全に理解した← pic.twitter.com/laKgGXUO8x
— tatematsu_san (@tk4_jj) September 14, 2019

やったこと(Y)

用意されていたコンテンツは、時間ギリギリでしたがなんとか完走することができました。
コンテンツのGit見ていただけるとわかりますが、かなり丁寧に書いていただいていたので、とても分かりやすかったです。

わかったこと(W)

A10さんのモジュールは、対象ホストに対してSSH接続し処理を行う、という形ではなく、aXAPIをAnsibleホストから発行する。
そのため、aAXPIで実装されている機能はほとんどのものが利用可能。(ACOS4.1以降が必要)
- つまり、会社で使ってるThunderのオペレーションはすべてAnsible化できるということ
  - つまり、Ansibleやらない理由がない。

つぎやること(T)

Visual Studio Code remoteを使えるようにする(済)
ブログに書く(済)
アンケートやる(済)
昨日あがっていたサンプルをのぞいてみる(今月は控えめに)
assert調べてみる(控えめに)

成果共有についての感想

tomoさん(非NWエンジニア)も完走されていて、実際の利用想定まで考慮されたコメント(テスト部分とか)をされていた。
自分はここまではまだ思い至らないので早く経験積みたい。
AzureをAnsibleで操作するスライドを用いた成果発表が突然はじまってびっくり。今回のも完走できているのもさらにびっくり。
みなさん、実業務の中で触れられていたりして、早く業務で使いたい気持ちが高まった。
@sky_jokerxx さんが証明書確認に使える仕組みと、自作モジュールのプルリク→マージされた話をされてていて、神だと思った。

全体的な感想

もくもく会参加したてのころは、どんなもんだろうと不安もありましたが、様々なコンテンツを体験するたび、Ansibleを早く仕事で使いたい気持ちがどんどん高まってきてます。

いつも貴重な体験の場を提供していただいているREDHATさん、今回のような貴重な場を提供いただいたソフトバンクさん、A10ネットワークスさんには感謝しかありません。

実績で恩返しができるように、頑張ります！

Ansibleはいいぞ。

A10はいいぞ。

2019-08-21

技書博読書感想文_02 大事なセキュリティの話をしよう

security 雑記

"#技書博"　読書感想文第二弾です。

今回は @yuki476 さんの「大事なセキュリティの話をしよう」です。

◆BOOTHでの紹介はこちら

booth.pm

本の概要とか所感

セキュリティガチ勢向けのゴリゴリの技術書ではありません。

「セキュリティ」というものを考えるための導入として、可能な限り技術的な要素をカットしたうえで、検討すべき要素とその考え方を、満遍なく、わかりやすく記載していただいていました。

「セキュリティって難しいんでしょう？」という方にとって、包括的に必要性や検討事項を知るには非常に有用な本だと思います。

ご本人のコメントにも「セキュリティは技術や仕組みでなく文化(BOOTHサイトより引用)」という内容があります。

平成29年にIPAから「サイバーセキュリティ経営ガイドライン　Ver2.0」が公開され、また世の中のセキュリティに関する需要もどんどん高まっています。

サイバーセキュリティ経営ガイドライン（METI/経済産業省）

ガイドラインの中にも「セキュリティ対策はコストではなく投資である」と記載があります。でも、結局お金はかかるのは事実です。でも、セキュリティインシデントを起こしたら一大事なので、失敗は許されない！なんていう風潮もあったりします。

そんな中、「セキュリティ対策」を突然任された、などの場合にお手に取ってみるのもいいのではないでしょうか。

私のとっての「セキュリティ」

私はセキュリティ関係のITシステムの設計構築運用保守などをやったりします。ただ、CTFに出たりなどのガチ勢ではなく、ゆるふわ勢くらいなもんです。

そんな私にとっての「セキュリティ」とは…

沼です。

それに尽きます。

いくらでもコストがかけられます。でも、完璧なんてありません。とはいえ、何かあると怒られます。

そのためには、どこかでボーダーラインを引いて、その状態でのリスクをアセスメントしたうえで、導き出されたスコアをもとに、そのリスクを「受容」するのか「回避」するのか、という合意形成が必要です。そうしなければ、ひたすら沼になります。

ここで、悪魔のフレーズとして「運用でカバーする」とかが出てくるともう最悪です。それやるための運用コストちゃんと見積もってますかといいたくなります。

このあたりの話を冒頭にしっかりと記載いただいていたため、とても共感できました。

沼の一例

例えば、以下のような非機能要件があったとします。

監査ログを取得すること
運用作業は、必ず個人が識別できる状況で実施し、関係者以外が操作できないことを担保すること

1個目は、Linuxで言えばsudo運用している場合のauditだったり、システムへのログインのログやコマンド実行履歴を取ったりと、なんとなくイメージがつきます。

問題は2つ目です。

これ、見方によってはどこまでも広がります。

運用環境への入退室をIDカードで識別しているから、システム操作アカウントは共有でもいいのでは？
いやいや、操作アカウントまで全部分けなきゃダメでしょ
でもそうすると、担当変更によるアカウント追加削除とかPW変更とかいろいろな運用オペレーションが増えるんだけど…
「関係者以外が操作できない」ってことは、運用ルームも専用にしなきゃいけないのか？
え？この運用金額で別室作るなんて無理ゲーなんだけど…
個人識別ってIDカードだけでいいの？生体認証とかいらないの？

などなど。

こういうのに「できる限り安全な方法で！」とか言われてしまうと困ってしまいます。なので、ちゃんとボーダーラインを引いて、そのボーダーでのリスクを明示したうえでジャッジ、合意形成する必要があるわけです。

アカウント共用はどうかなーと思いますが、でもそういう妥協をするケースもあると思います。

例を終えて

運用シーンをベースにセキュリティ関連の沼の例を書きましたが、こういう点だけでも材料がいっぱい出てきます。

なので、そういう要素を全く書かずにここまできれいな形でまとめられたのは、すごいと思いました。

結局、一つ例を出したとしても「それってうちの環境だと無理なんだよな…」という場合多いと思います。だからこそ、その組織や環境に応じて具体化するためにも、共通事項としての考え方を身につけるのは非常に重要で、そこをうまく表している本だなと思いました。

ISOごっこをやっている方々への啓蒙もかねて、会社で回し読みしてもらおうと思ってます。

2019-08-15

Ansibleもくもく会に現地参加してきました。

Ansible

Ansibleもくもく会が2019/8/13に開催され、通算5回目で初めて現地で参加(成果共有枠)することができました。

快く有休取得に首を縦に振ってくれた会社のメンバーや、送り出してくれた奥さんには本当に感謝です。

会場では、RedHatのすぎむらさん、Teihiさんとご挨拶することもできました。お会いできて本当にうれしかったです。今後ともよろしくお願いいたします。

感謝の意味も込めて、今回はだいぶマシマシな内容にしたいと思います。

はじめに
Ansibleもくもく会のNW編のサービス寄りトポロジ
Ansibleもくもく会のNW編のルータ寄りトポロジ
実際にやったこととかログとか
- RTR1(Cisco)側RouteTable
- RTR2(Arista)側RouteTable
次回もくもく会の日程について
成果発表の内容について
Ansible飯への参加について
今後について
おまけ

2019-08-07

効率化に関する私の考え方

Ansible 雑記

ソフトバンクさんが、「Half & Twice」という社内スローガンを出されています。

時代の変化が求めるワークスタイルとは〜ソフトバンク流「働き方改革」の事例～ - ITをもっと身近に。ソフトバンクニュース

これは、”半分の時間で生産性を2倍にしよう”という考え方です。不勉強で申し訳ありませんが、私はこのスローガンは、先日のAnsible Automatesで初めて知りました。

一見無茶に見えますが、個人的には割とドMなので、こういうのを出されると燃えるタイプです。

あんまり話はつながっていませんが、色々と考えを整理するために、効率化に関する自分の考えを書いてみます。

効率化の定義

私の考える「効率化」の定義は、以下の通りです。

ものごとを現在よりも短時間で実施する
同じ時間をかけても、より品質の高いものを提供できるようにする

決して、「新しいものを作り出す」とか「すべてを同じ方法で実現する」とかではないのがポイントだと思っています。

効率化＝自動化？

これは、明確にNoだと思っています。

自動化は、効率よくものごとを行うための一つの手段でしかないと考えています。

例えば、「手動でファイルサーバのデータを整理した」「業務フローを整理し、書類にまとめた」というのは、自動化ではありませんが、これは「効率化」の手段としては正しいアプローチです。

ファイルを探すのに散らばっていてどこにあるかわからず時間がかかる。誰が知っているかわからないから、手当たり次第に相談する。こういった課題を解決することで、「無駄を減らす」という形で効率化を実現しているからです。

利益＝売価 - 原価

この商売の原則と同じです。利益を出すには、原価を下げるか、売価を上げるか。

原価は、同じ方法を継続していても下がりません。なので、大量購入だったりもっと安い仕入れ先を探す、などの手法で原価を下げることを検討します。

単純に売価を上げても、それを喜ぶ人はいません。なので、大量に売れるために広告をうったり、付加価値をつけることで、より商品価値を高める必要があります。

まあ、こんな話はいまさら言われるまでもないことだと思いますが。

売り上げ論に関してはど素人なので、原価を下げる方法の話になるのですが、ITの現場でこれを考える場合、「無駄を減らす」というのがまずは考えるべきだと思っています。

Ansibleを例に挙げて考えてみる

私が最近お熱なAnsibleですが、これはRedHatさんの「自動化2.0」の中心に位置するプロダクトです。

「導入効果で実作業時間が1/30になった」
「フロントエンドと連動させて運用に手がかからないようになった」

上記のように、非常に効果が高いと思える導入事例が多いです。

ただ、

「Playbookでいろいろな仕組み実現しようとすると無理やり感が出てつらい」
「コーディング規約をまもってくれない」
「Playbook化する前に標準化が必要だった」

とかの、つらみ寄りの言葉も目にします。

Playbookは可読性が高い。冪等性があると良い。これは本当のことだと思います。

TowerやAWXを入れると、ワークフローで最小限のPlaybookの組み合わせで行けるから部品化しやすい。

これも本当だと思います。

ただ、それらが求められる現場や環境だけではないはずです。

単純に、「作業時間を短くしたい」「かかる人手を最小限にしたい」ということがやりたかっただけなはずなのに、「自動化」することが目的になっている。

その「自動化」の手法に合わせるために、結構な努力をする。

結果、なんか当初考えてたのとは違う結果になってきて、ぐぬぬ・・・となる。

割とよくある話ではないでしょうか。

手段に盲目にならずに、自分が本当に必要としているものを見極める必要があると思っています。

私としては、基本的に「無駄を減らす」ということを効率化の一丁目一番地で考えていて、それと照らし合わせて適切な場所で、適切な方法を取れればそれでいいと思っている人です。

「自動化2.0」のサイロをなくすというような考え方とは反することになりますが、検討の結果が、ある場所ではAnsibleなどになり、それ以外では別のアプローチになる。それでいいと思っています。

こんなことを言っている背景

Ansibleなどの自動化ツールで実現できるのは、以下の点だと思っています。

作業トリガーの自動化
作業の標準化
処理の自動化

これらを実現できるのは素晴らしいことです。

ある作業の処理待ちで次の自身の作業まで3時間待つ。これをトリガーの自動化でだれでもできるようにして無駄を減らす。

非常に素晴らしいです。

作業手段が標準化され、統一されることにより、引継ぎにかかるコストが大幅に削減された。

これも素晴らしいです。

実際の作業が省力化され、作業をITに任せて他のことができるようになった。また人手でやりよりもはるかに確実で効率的に実施できるようになった。

本当に素晴らしいです。

でも、そこにたどり着くまでに、いろいろな学習をしたり。準備にものすごく時間をかけたり。意識改革までしたり。

あれ、それがやりたかったんだろうか。と疑問に思ったことはないでしょうか。

もちろん、エンジニアにとって前に進むことは求められますし、新しいことを学んでいくことはとても重要なことです。これは「環境や時代に合わせて適応していく」という、「変化」なのだと思っています。

ただ、そのような「変化」ができない人や環境でも、効率化は求められるんです。私の周りにも、そんな人たちはそこかしこに居ます。

そこに対して、「時代遅れだ」とか「勉強しない奴はこれだから」とマウントを取ることはできると思いますが、変化しないものは変化しないんです。

であれば、やりかたが間違っている、と考えることもできるはずです。この時点で「あいつらには無理だ」とあきらめるのはまだ早いです。

「無駄」とはどういうことか？

ツールを変更することで手順を変化させる。これは、受け入れのコストがものすごくかかります。

上記のような、新しいやり方ができない場合でも効率化が求められます。

そういった場合には、徹底的に「無駄」を排除することが最も効果的だと思っています。

「無駄」というのはそこかしこにありますが、例えばある特定の作業を行うときを考えてみましょう。

手順書を目で追っていき、工程ごとにチェックを入れる
手順書に従い、画面の操作を行う
手順書に記載されたとおりに、コマンドを手動やコピペで入力する
入力された内容を複数人のダブルチェックで目視確認する。
手順書に記載された形の結果になるか確認する。異常があればエスカレーションする。

大体の場合、最後の判定の部分が最もコードを長くにしてしまうものだと思います。いわゆる、「エラーチェック」の部分だと思います。

決して「エラーチェック」の重要性を軽んじているわけではありませんが、それって本当に自動化しなきゃいけないんでしょうか？

判定基準が明確なら、別に目視でもいいんじゃないでしょうか？

人手による運用のリスキーな点は、「オペミス」だと思ってます。オペミスは、手順や判定基準がしっかりしていない場合に発生することが多いです。

文字が読みにくかったり、絶妙にTypoっていたり。それを目視で確認して手動で入力したり、慎重に1行1行コピーして貼り付ける。

私も、CiscoのACLをコンソールでいじる時なんかはすごい慎重になったものです。

私が考える最も「無駄」なポイントは、この「入力行為」です。

入力は、人間がやるのよりも、機械がやるほうが確実です。

入力を誤るオペミスは、機械がやっても間違えるならそれは手順が悪いんです。

なので、確実に手順通りに実施する機械があるのであれば、あとは手順の精度の問題です。

であれば、その仕組みを作ってやればいい、と考えて、実際に作ったことがあります。

前の部門で類似のオペレーションを何度もやるようなシーンがあって、そこに適合するなと思ったのがキッカケです。

でも、メンバーは「変化」には敏感なメンバーでした。なので、それは中身を知らないといけないような仕組みにはせず、手順の精度を上げればいい、かつ見た目は変わらない、入力だけをやってくれる、という実装にしました。（ちなみに、中身も大したことはないです。）

止まる部分には特定の文字（手順書上不自然でない文言）を手順に入れるだけで、止まってくれるようにしました。ここで目視で判定をするようにしました。

メンバーの教育は5分で終わりました。今ではなんの気兼ねもせずにその仕組みを使ってくれています。

結果、一回の作業の時間は1/3になりました。

Ansibleの話よりも効果は低いようにも思えます。でも、本当にそうでしょうか？

効果がすぐに出る。ある程度網羅性に目をつぶれば、どんなものにでも応用できる。メンバーの教育もほとんど要らない。冪等性なんて求めてない。

教育そのものが無駄とは言いませんが、結構なコストです。抵抗もあります。

こんなふうに、部分的に形は変えずに無駄な部分だけを省く。こんな形の効率化があっても良いよな、と思います。

もちろん、そこで止まるか、踏み台として先に進むかはそれぞれです。

それでも、一足飛びにやるよりも、確実な一歩を踏み出す。その結果生み出された時間でもう一歩目を踏み出す。そんな形のステップもあっていいと思います。

前に進む材料は一つではないはずです。読んでいただける方は少ないと思いますが、みなさんも盲目にならないようにご注意ください。