"Excelにさよなら"社内のIT資産管理ツールにSnipe-ITを導入した
Excelへの憎しみを生む業務「機器管理」
情シスの仕事のうち、大事だけどくそ面倒臭い仕事のうちの一つ
機器管理
誰がどのPCを使っているのか。 それだけを管理したい。 そこで、まず最初に何を使うって、そらExcelですよね。
ただ、この機器管理の対象は昨今どんどん増えていく状況にあります。
PC、社内携帯(スマホ)、タブレット、ウェアラブルデバイス、スマートスピーカーなどなど
で、最初はそれでいいんですが、運用を続けていくと、
社員の退職、入社
端末故障による交換
紛失
イベントなどで一時的な用途による貸し出し
なんかの出入りが発生していきますよね。
しかも、携帯電話なんかだと、退職による返却があった後、それをすぐに違う人に払い出すと前の人宛の電話がバンバンかかってきたりして、一定期間寝かす。などの細かい運用が求められます。
だが、しかし、Excelで管理できるのは、 今 のみ
履歴をExcelで管理しようとするとすぐに限界が来ます。
社内で一人だけがそのExcelを管理しておけば、その人の記憶を頼りに運用が回ることもありますが、複数人で管理したり、管理者が変わったりした時に必ず混乱に陥ります。
じゃぁ、履歴管理もできるツール入れようぜ。
ということで、色々探した挙げ句にたどり着いたのが、今回導入したSnipe-ITです。
Snipe-ITの概要
Say Goobye To Spreadsheets! という謳い文句の通り、今回の要件にビタッっと適合するOSSのツールです。
SaaS型のサービスとしても提供されており、また、OSSなのでソースコードも公開されています。
なので、導入の仕方としては、以下3パターン
No | 導入方法 | 向いてる人 | 費用 |
---|---|---|---|
1 | (自社やクラウドに)サーバ立ててインストールする | 安いのは正義 | 0 or 1200円/月(AWSでEC2の最安サーバ) |
2 | SaaSサービスを契約 | スキルないけど金はあるしすぐ使いたいんや | 4500円/月($39.99) |
3 | AWSのマーケットプレイスでインストール済みイメージ買ってAWSで運用 | 折衷案 | 2000円/月(AWS EC2+イメージ使用料) |
うちは、導入時に時間があんましなかったので、3番を採用しました。
で、実際使ってみてわかった機能的な部分を紹介します。
Snipe-ITの機能
管理対象
よくあるPCや携帯だけでなく、色んなタイプの機器が管理できるようになっています。
- 資産(Asset):機器端末 例:PC、携帯
- 付属品(Accessory):複数台管理していて、Userに1つづつ在庫を割り当てれる 例:マウスやキーボード
- ライセンス(License):ソフトウェアなどのライセンスの期限管理ができる 例:Office系ソフトやAdobeのソフトなど
- 消耗品(Consumable):割り当てる度に在庫数が減っていく(在庫管理ができる) 例:紙やインク
- 構成部品(Component):Userに複数数量を一度に割り当てれる 例:PCのメモリ
- 人物(User):人や部署。これに対して上記5種類の資産を割り当てることができる
うちが実際使ってるのは、人と資産(Assets)しか使ってません。ライセンスは今後使う予定
履歴管理
- この機器が誰に使われてきたのかの履歴
- このユーザーがどの機器を使ってきたのかの履歴
の2方向からの履歴が見れます
また、機器自体にも、修理などのメンテナンスの履歴を登録して別途管理することができます。
カスタムフィールド
こういうWebの管理システムでは当たり前のカスタムフィールドを自由に追加できます。 ただ、注意点なのは、ユーザーに対してカスタムフィールドを追加できません。 資産側にのみ、追加可能です。
何が困るかというと、
今回外部に貸し出している機器については、月でまとめてレンタル料を請求するという業務があるのですが、機器を割り当てている課金対象のユーザーを抜いてそのデータを作りたい。
でも、ユーザー側にはカスタムフィールドが追加できないので、機器側に課金するという項目を追加し、そのフラグを立てた機器をユーザーに割り当てる。
ということをしなくてはならず、ちょっと不便。
機器のステータス管理
デフォルトのステータスの他に自由にステータスを追加できます。
作成したステータスごとに、機器を割り当てできるか/できないかの設定もできます。(紛失 のステータスなら割り当てできないとか)
ユーザー管理
細かい権限管理が可能です。閲覧しかできないユーザーも作成可能です。
なお、機器を割り当てるユーザーに対してログインを許可するかの設定を行う感じなので、実際の社員(機器の利用者)と、システムの利用者が同じユーザーとして管理されます。
レポート(CSV出力)機能
条件を指定して、CSVでデータを抜くのはできます。
ただ、標準の項目のうち、一部にしか条件を指定できません。なので、カスタムフィールドに対しても条件が指定できないため、不便で。
また、よく使う条件を保存する機能もないため、そこもちょっと不便。
検索条件の保存機能は、2017年12月にgithubに要望が上がっているが、まだ実装されてません。
あと、文字コードがUTF-8なのでエクセルで開いたら日本語が盛大に文字化けします。これはどっちかってーとエクセル側で読めるようにそろそろなんとかして欲しい。
インポート機能
CSVのインポート機能があるので、Excelからの移行などは、簡単ちん。
ただ、項目の説明が公式サイトでもわかりにくいため、トライ&エラーで仕様を把握するのに最初は苦労した。
API
RESTのAPIがあります。でも、使ってないから、利便性はよくわかん。
標準のCSV出力機能が不便なので検索系のAPIが無いかを見たけど、無さ気。
注意点
SaaSやクラウドで使う際の注意点
ユーザーごとにタイムゾーンを設定できません。
なので、SaaSやクラウドの際は、UTCで時間が表示されてしまいます。
実際機器管理で時間まで厳密に管理しないのでそこまで業務には影響ないですが、払い出した日がいつかとか調べる時に読み替えが必要になったりするので微妙です。
日本語
日本語の翻訳がじゃっかんクソです。わからなくもないけど、初見で意味がわからない部分があります。 例えば、管理対象についても
資産 :Asset
付属品 :Accesary
ライセンス : License
消耗品 :Consumable
構成部品 :Component
人物 :User
と翻訳されてますが、このシステムの根幹をなすオブジェクトに対してこんな感じで訳されると色んな画面で表示された際に意味がわかりにくい。
いっそのこと、英語をそのままカタカナにした方が、スッと入ってくる気がしてます。
あと、表記の揺れもあったりします。
外部の翻訳サービスの「crowdin.com」を使って翻訳しており、そこに対して修正案を投げることもできるので、投げてみたりもしましたが、反映されるのいつやねんって感じです。
自分でサーバ立ててる場合は、日本語ファイルを直接触って変更することも可能です。
うちの場合は、バージョンアップとかした際にそこらへんの移行も面倒なので現状は我慢して使っています。
マニュアルの情報量が少ない
インポート機能のところでも書きましたが、公式マニュアル(英語)の情報量が少なくトライ&エラーで調べながら機能を理解する必要があります。
インポートの機能を調べる際は、最終的にphpのソースを読むとこまでいきました。
総合評価
おおむねExcelに比べれば200%まし。機能的にもコスパ的にも満足です。
ただ、サポートがちょっとね。という感じなので私みたいに、Excelへの怒りゲージがMAXになった際にその怒りパワーで初期導入を乗り切って貰えれば良いかと思います。
Apple IDが「このユーザはactiveではありません」と言われて使えない
会社でレンタルしてるiPhoneをキャリアに返そうとしてた。返却時の手順として、
「iPhoneを探す」をオフにして、初期化して返してくれよな!
って書いてたのでやろうと思ったらApple IDのログインが失敗してしまいます。。。。どうしよ、今月中に返さなきゃならないのに・・・。
噂では、不正な使い方をしたユーザーを自動検出してアカウントをロックするという仕組みがある(そして、それはちょこちょこ正規アカウントも凍結してしまう)との噂を聞いたことがあったので、それに当たったかと思い、解除のために、Apple のサポートに問い合わせ。
電話したら、混み合ってるので予約が可能です。というので、20分後を予約。
すると、いきなり電話がかかってきて、しかも音声案内で
「○○様でお間違えないでしょうか」
とかきたのでうおー、すげーなと思いきや、「ただいま混み合っているので、お好きな音楽を聞きながらお待ち下さい」
ということで、結局待たされる。予約機能の意味って!
そんなこんなで5分くらい待つとようやくサポートの人につながって簡単に説明する。
「AppleCareスペシャリストの吉田(仮名)が責任を持って対応します!」
と力強く言ってくれて一旦待ちに。しかし、しばらくして、スペシャリストの手を持ってしても難しかったのか、「本国の開発部門に問い合わせが必要になってしまいました。5営業日くらい必要そうです」とのご回答。
電話対応が良さげだったので、我慢強く待つことに。
4日後の翌週の月曜日、何気に触ってみたらApple IDで正常にログインできてた。アメリカの開発部署で凍結を解除してくれたのだろう。
無事初期化してキャリアに返送できましたとさ。
PostgreSQLでポイントインタイムリカバリ(PITR)で指定した時間で止めれなくてハマった話
最新までロールバックされちゃうんです
新しいシステムで、Windows Server上でPostgreSQL 10.4 を使うことになり、ポイントインタイムリカバリのテストをやっていたのですよ。 で、ちょっと検索すれば、そのやり方は出てくるし、マニュアル読めば普通に書いてる。Windowsだけど、そこにほとんど機能差は無い。
で、確かにアーカイブログ(WAL)を取っといてベースバックアップを戻して、PITRを実行すると、確かにその状態に戻るんです。 戻るんです。が、
デフォルトだと、READ ONLYモードでリカバリかかるので、通常モードに切り替えるために、サーバを再起動したらええんかいなと思ったら、
2018-10-18 17:44:52.555 JST [3332] LOG: database system was not properly shut down; automatic recovery in progress
2018-10-18 17:44:52.558 JST [3332] LOG: redo starts at 1/29000028
2018-10-18 17:44:52.559 JST [3332] LOG: consistent recovery state reached at 1/2A001088
2018-10-18 17:44:52.559 JST [3332] LOG: invalid record length at 1/2C000098: wanted 24, got 0
2018-10-18 17:44:52.559 JST [3332] LOG: redo done at 1/2C000028
なんか自動でロールフォワードかかっとる。
結果、ポイントインタイムリカバリではなく、最新時点までリカバリがかかってしまった。
うーん、どうすればいいんだ?
キーは"タイムライン"
マニュアルを読み込むも、いまいち記載がない。
なんとなく、タイムラインをスイッチすればいいっぽいのだが、
recovery_target_timeline ='2'
とか指定して起動しても、そんなタイムライン存在しません。とか言われて起動しない。
ということで、色々試してたら、
recovery.conf内に
recovery_target_action = 'promote'
をセットしてDBを起動したら、自動でタイムラインがSwitchされて、通常モードで起動された。
2018-10-18 19:30:53.700 JST [2360] LOG: database system was shut down in recovery at 2018-10-18 19:27:55 JST
2018-10-18 19:30:53.700 JST [2360] LOG: starting point-in-time recovery to 2018-10-18 19:19:10+09
2018-10-18 19:30:53.721 JST [2360] LOG: restored log file "000000010000000100000031" from archive
2018-10-18 19:30:54.653 JST [2360] LOG: redo starts at 1/31000098
2018-10-18 19:30:54.699 JST [2360] LOG: restored log file "000000010000000100000032" from archive
2018-10-18 19:30:55.607 JST [2360] LOG: consistent recovery state reached at 1/32002BE8
2018-10-18 19:30:55.608 JST [5616] LOG: database system is ready to accept read only connections
2018-10-18 19:30:55.608 JST [2360] LOG: recovery stopping before commit of transaction 9738, time 2018-10-18 19:19:14.630902+09
2018-10-18 19:30:55.608 JST [2360] LOG: redo done at 1/32002BE8
2018-10-18 19:30:55.608 JST [2360] LOG: last completed transaction was at log time 2018-10-18 19:19:04.706312+09
2018-10-18 19:30:55.635 JST [2360] LOG: selected new timeline ID: 2
2018-10-18 19:30:56.643 JST [2360] LOG: archive recovery complete
2018-10-18 19:30:56.755 JST [5616] LOG: database system is ready to accept connections
あと、walファイルの名称にも、TIMELINE IDが埋め込まれているらしくそれっぽく変わった。
結論
最初はちゃんとリカバリできてるか確認するっしょ?
なので、
recovery_target_action = 'pause'
で起動して、READ ONLYモードしてあげるよ。
そいで、大丈夫だったら、
recovery_target_action = 'promote'
にして、再起動かけたら、リカバリ完了だよ。
(recovery.confもrecovery.doneにファイル名が自動で変換される)
ということでした。マニュアルにはこの手順書いてないっぽいんだけど。俺が探しきれてないだけなのだろうか。