#はじめに
私が運用改善を目的としてやっている、ひとりDevOpsの雑記です。
個人的な立場による見解が多いので、全ての場合において当てはまるとは限りません。
当てはまらないということは、私のように苦しめられていないので大変良いことです。
私のように苦しめられている人の助けになれば幸いです。
#要約
ひとりDevOpsは楽しい！！（動けば）
#背景
巷のDevOpsは継続的インテグレーションの思想が強いように感じます。
すごく曲解すると「最低限のシステムを納期までに作って運用スタート！！運用しながら開発もすればいいこといっぱい！！」みたいな感じです。
まぁ、システムは稼働しないとお金を稼がないですし、稼働優先は当然です。
話が変わりますが、世の中には開発と運用が協力できない現場があったりします。
例えば、運用請負として他の会社が作った顧客のシステムを運用する現場。
組織が違うので連携も取りにくいですし、開発側のチームは解散していたりすることもあります。
そんな運用の現場に開発要員が配置されるはずもなく、マンパワーによるパワフルなオペレーションによってシステムが稼働してたりすることもあります。
そんな現場でﾌﾟﾛｸﾞﾗﾐﾝｸﾞﾁｮｯﾄﾃﾞｷﾙ 私が「運用改善」を目的として始めたひとりDevOpsのお話です。
偉い人「自動化しろ！！」
「自動化で運用の工数削減！！エンジニアの空いた稼働を他にあてて利益をアップ！！」
という戦略で偉い人から自動化しろ！！と言われたことはありませんか？
私はあります。
しかし、運用の現場に自動化しろと言われても無いものがいろいろあります。
私の場合は、以下が現場にありませんでした。
- プログラマ(Coder) ←重要
- 時間
- 予算
- 度胸(変更は運用にとって脅威)
特にプログラマはコードを保守していくのにも必要なので、運用現場に常駐もしくは関わりやすい状態であるのが望ましいです。
しかし、私はﾌﾟﾛｸﾞﾗﾐﾝｸﾞﾁｮｯﾄﾃﾞｷﾙ程度なので、本当は私以外で人員が欲しかったのですが予算もないので仕方なく私がやることになりました。
時間もスキマ時間を上手く使うしかないですし、予算はほぼゼロ、度胸は未来の自分と責任とってくれそうな上司に丸投げです。
私の熱いDevOps活動、Devカツ。
始まります(フフッヒ)
紆余曲折を経て、現在のひとりDevOps
スキマ時間でいろいろ取り組み、1年が経過していろんなことが見えてきました。
- 自作ツールの管理はLAN環境に用意したgitlabが便利。プロジェクトごとにWiki作ったりissue発行できるので、ツールの公開やユーザレビューの場所としても有用。
ソースに顧客情報直書きしてもローカルだし問題ないよね(冗談） - なるべくコードの行数は短く。短いコードは処理を追いやすい。
- 「複雑でツールの作成に時間がかかりすぎる」＆「コードの保守が大変になりそうな作業」はツール化しないほうがいい。
- コードの変更が頻繁に起こりそうなら、保守工数が多くなるのでツール化の優先順位を下げる（効果的なところから）。
- 効果的なところからツール化すると、空き時間が増えて、スキマ時間が増える（気がする）。
- ツールの処理の中に人間をうまく組み込むのも一つの手法。
開発側が「運用でカバー」という理由もわかるようになった（納得はしていない） - 人間の処理は確実性がないので、脆弱性としてうまくリスク管理する。
- 作業の工数削減よりも人間のオペミスを減らす方が、事故報告書作成の工数を減らせるので効果的。
- 偉い人はコードの保守にかかる工数がゼロだと思っている！！
作ったら終わりじゃない。始まりなんだぞ（キレ気味） - ツール起因のオペミスは原因がはっきりしているので、対策もすごく妥当。
人間の確認不足が原因で、ダブルチェック、トリプルチェックの対策は不毛でしかない - ツールの動作試験項目が動作保証になるので、記録に残る試験をなるべくやる。
- 試験結果でツール導入の決議を偉い人に決めてもらって、責任も負ってもらう。
- ツールのトラブルの責任をプログラマ個人が持たないようにする。
- 難しいことを一つやるよりも、簡単なことをいっぱいやったほうがいい（一つのことをうまくやれ）
- 時には諦めも肝心。可能不可能だけでなく、費用対効果のモノサシも使って判断する（面倒なことはなるべく避ける）。
特に試験は重要で、「試験項目の範囲でツールの動作を保証する」ことで責任問題がわかりやすくなります。
ツールが正しく動くことの指標にもなり、仕様書の役割にもなるのでなるべく試験は徹底したほうがいいです。
あと、オペミス削減が隠れた工数削減につながるのを身をもって痛感したのもいい経験でした。
しかもオペミス削減はオペレーションの品質向上にもつながる。。。金になりそう。
#言語について
チームでプログラミング言語を統一しようとすると戦争が起きるらしいのですが、ひとりDevOpsでは争う相手がいないので起きません。
好きな言語を使いましょうーーと言いたいところですが動作環境のOSや保守のことを考えて使い分けるのが良いと思います。
個人的見解として、シェル系言語とスクリプト系言語とクロスコンパイル系言語の3種でそれぞれ1つ以上は書けるのが理想です。加えてHTML5(javascript)も書けると鬼に金棒です。
私はシェル系でBashとPowerShell、スクリプト系でPython、クロスコンパイル系でGolangとRust、そしてHTML5でツールを作る事が多いです。
シェル系言語
OSのシェル上で動作するスクリプト言語です。
強みとしてはシェル系のコマンドが簡単に使えるので、OSでのオペレーション作業をツール化する際に役立ちます。
私はLinux向けにbashスクリプト、Windows向けにPowerShellスクリプトを使い分けています。
特にPowerShellは.NETの資産を利用でき、特にWindowsのツールを作るのにすごく強力なのでおすすめです。
参考URL：（そのうち増やします）
PowerShellでフォルダ監視をする
PowerShellとRLoginで大量サーバ管理
運用効率化のためにツール開発＆自動アップデートの仕組みを作った話
PowerShellでフォルダ監視2nd(PowerShellのおかげで女子から相談された話)
スクリプト系言語
ここでは、インタプリターで実行するPythonやRuby等を指します。
自由度が高いので、複雑な処理系をスクリプト系で書くことが多いです。
Python、Ruby、Perl、PHPあたりがメジャーどころかなと。
私は主にPythonを使っています。
ライブラリ群が強力ですし、コードが読みやすいですし、よく使うCentosにプリインストールされてるのが主な理由です。
Rubyはあまり良くわかりませんが似たようなものだって誰かが言っていました(責任転嫁)
あまり好んで使いませんが、場合によってPHPを書くこともあります。
参考URL：（そのうち増やします）
クロスコンパイラ系言語
各プラットフォーム向けに実行バイナリを生成できるのが強みです。処理が速い。
GolangとかRustとかNimとかetc...
処理速度を気にするツールや、WindowsとLinuxのマルチプラットフォームで使われるツールを作るのによく使います。
Golangは学習コストが低いので時間のない初学者におすすめ。
数行でWEBサーバが実装できたりします。
Rustはボローチェッカーとの戦いが楽しいので、個人的に好きです。
私はNimをよく使っています。簡単に書けてコンパイルも早いしいい感じです。
参考URL：（そのうち増やします）
Coderでお試しNim開発環境を作る
HTML5(javascript)
ブラウザで実行されるスクリプトです。
私は文章整形ツールを作るときに使うことが多いです。
HTMLファイルをブラウザで開けば使えるので、ある意味マルチプラットフォーム。
WEBサーバで公開すれば、ツールへのアクセスも楽なので意外と重宝します。
参考URL：（そのうち増やします）
おすすめのツール（OSSとか）
GUIの自走操作「sikulix」
OpenCVでの画像認識をベースに、GUI操作を自動化することができます。
とても簡単に自動化できちゃうので、おすすめです。
（ただ、挙動が安定しないこともあったりするのでそこは要注意です）
参考URL：
自動テストツール「SikuliX」でお手軽RPA
監視ツール「Zabbix」
個人的に慣れ親しんでいる監視ツールです。
他の監視ツールと比較して、軽いのがいいところです。
あと、WEBAPIがあるのも魅力の一つ（外部ツールと連携させやすい）。
ZabbixAgentを使ってリモートマシンをゴニョゴニョしたり、定期実行ツールのログを収集させたり、いろいろと応用ができます。
参考URL:
あぱーブログのZabbixカテゴリ
最後に
時間に余裕ができたら自作ツールの紹介とかしたいです。
追記
2018/09/12 PowerShellでフォルダ監視をする記事を書いたので追記しました。
2019/05/14 クロスコンパイラ系言語にNimを追加しました。あと参考URLを追記。