8/11 血糖値測定器と戯れる

そろそろ来月の通院に向けて血糖値入力しなきゃなーと思いつつ、ふと気づいたんですよ
\俺前回の通院から一切メモ取ってない/
はい、患者として色々間違ってますね 〇| ̄|_

だがあきらめるのはまだ早い!ということで、今回は今使っている血糖値測定器と色々やりあってみました

何を使ってるの

今使っている機種は、 Abbott の FreeStyle Precision Neo ってやつです。うん、地元のドラッグストアだとオムロンさんがOEMしてる「いっこまえの」機種になっちゃってネ。
病院から処方(貸し出し)されてるのは怖くて使えないので、同じのをネット通販で手に入れました!←実に脳筋

いままでどうやってたの

  • 毎食前、寝る前に血糖測定します。
  • 実際に食べる直前に注射するので、そのタイミングで持効型・速効型の単位を入力します。(プレシジョンエクシードではそもそも投与量の入力はなかったので、記憶で)
  • 血糖値ノートにメモします。
  • メモした結果をひたすらスマホに入力(!) します。

で、どうかわるの

この子、なんとUSB接続できるんですよ。

デバイスは、USB接続した先のWindowsパソコンからは「HID」つまりキーボードとかと同じ扱いになるみたい。
うーんどっかで聞いたなこれ…BadUSBとかと同じ仕組み?みたいな?

まあそれはともかくとして。

Auto-Assist ってソフトをインストールします。
http://www.myfreestyle.jp/products/freestyle-precision-neo.html

インストール後、あらためてぶちっと接続すると、測定器をプログラムが認識してあとは勝手にレポートを出力してくれます。
っていっても、日糖協さんのノートみたいなスマートな表示ではなくて、1ページに2-3日分しか表示されない…め、めんどくさい(めんどくさいいうな)

ま、まあアレですよ。電子ペーパーの画面とにらめっこしなくても、後で数日~数週間(おい)まとめて振りかえって確認できるのは便利!
ていうか寝る前にコンスタントに書き出せよ自分!

残念だったこともあるのぜ

まあ、ものぐささんにはありがたいレポート出力機能。いっこだけ残念だったこともあります。持効型は、特性上一回セットすれば直前の値がプリセットされます。が、速効型は記憶してくれないみたいなのです。
せめて普段からx単位ってプリセットできたら、体調と食べる量に合わせて微調整できるんだけどなーと。毎回0からカウントしてくの、けっこうめんどくさいのよね(だからめんどくさいいうな)
※速効型のプリセットは、医療従事者向けのオプションみたいです。ゲプー。

ま、まあめげずに、主治医と健康へのスプリントまわすよー!

6/21 future社のセミナーに参加して板挟みを感じる

久しぶりに企業主催のセミナーに参加したよ!いろいろ辛い目にあったけどまずはいい話だけ書くよ!

futureさんのセミナー

講師は、future社のhogehugaさん 、kotakanbeさん。

第一部

第一部は、 hogehugaさんによる脆弱性トリアージのお話を伺うことができました。
OWASP TOP10 で言うとこの、 A9 Using Components with Known Vulnerabilities が該当するのかな。

  • 成果物によって、脆弱性対策の打ち方が変わる
    手作り(php/java等で書いたもの)やtarballを自分でビルドした場合と、yum/aptでパッケージをインストールしたものの2種類があるとして。
    手作りのスクリプトの場合:tripwire などで変更監視
    yum/aptの場合は、vulsなどで監視
    がそれぞれ行えそうです。
    一番厄介なのは、tarballを自分でビルドした場合かもしれませんね。(といいつつ、1x年前は自分もtarballからビルドしてたような)
  • 脆弱性のトリアージは、物差しを使う
    SCAPと呼ばれる考え方。Security Content Automation Protocol 。 https://ja.wikipedia.org/wiki/Security_Content_Automation_Protocol
    CVE CCE CPE CWE CVSS XCCDF の6種類。
    CVSSは、基本値が通常記載されるけど、企業文化で環境値が大きく変わる。「スコアより、ベクタ」
    「このシステムは、とにかく落とされないことが大事!機密情報はないよ!」という場合は、たとえ基本値が高くてもそれが機密性には影響するが完全性可用性への影響が小さければ、その分リスクは小さく見積もることができるし。一方で、基本値が低くても可用性に多分に影響するのであれば、リスクは大きく見積もる必要がある。(この話、越後湯沢でリクルートさんの発表で聴いたなぁ)
    機密性は大事だけど、DoSで落ちる分には我慢するよーということであれば、また同じように天秤を傾ける必要があるね。
  • 情報ソース
    本当に欲しいデータだけとは限らないので、そこは気を付ける。
    xploitdb: PoCもある。みんな見ている。
    GitHub: おおむねソースコードの形式で公開されている。
    中国のサイト とにかく中国語圏はとにかく人口が大きい。CVE-2019-2725(Weblogic)は中国語圏のエンジニアが対策を出していたとか。
  • 脆弱性と、企業の運営リスクを天秤にかける
    全体的にみて、リスクを回避できれば良い。
  • どうやってパッチを検証するか
    本番環境とステージング環境を往復するとか
    やっつけ本番だが、FOA-CROモデルで乗り切るとか

…ざっとメモを書きだしただけでこれだよ。ホントはほかの資料も読まないと頭が整理できないよ。
これ、1時間で駆け足とか無理なので!(ホントしんどそうだった)
– 情報セキュリティ早期警戒パートナーシップガイドライン (倫理的なあれ)
https://www.ipa.go.jp/security/ciadr/partnership_guide.html
– IPA謹製SCAP本
https://www.ipa.go.jp/security/vuln/SCAP.html
– IPAテクニカルウォッチ「脆弱性対策の効果的な進め方」
https://www.ipa.go.jp/security/technicalwatch/20190221.html
https://www.ipa.go.jp/security/technicalwatch/20150331.html

第二部

第二部は、 kotakanbeさんによるvuls/FutureVulsの紹介。

  • vulsの導入
    https://www.ipa.go.jp/security/technicalwatch/20190221.html
    https://vuls.io/https://github.com/future-architect/vuls
    dockerのvulsインスタンスを立てるのもよさそう。というか海外ではdockerインスタンス多いそうです。
  • そういえばあの脆弱性どうだっけ
    CVE-2019-11478 近傍のselective ack 事例がちょうどネタに向いていた感じがあります。
    (‘A’) RHEL5は影響を受けるけどEOLだから対処しないよ!
    なかなかこのくだりがかっこよかった。(そこか)
    https://access.redhat.com/security/vulnerabilities/tcpsack
  • 有償プラン= futurevuls
    月額3980円/1ノード 。有償プランでは、まさかのwindows serverにも対応しているとのこと。ま、まあWSUSみたいな診断~アップデートが行える感じね。
  • オンプレミス版でのインストールタイプ
    1.Remote Scan mode
    対抗の各ホストにSSH接続して巡回するモード。
    2.Local Scan mode
    いわゆるスタンドアロンモード。
    3.Server mode
    HTTPサーバとして他ノードからの待ち受けを行い、他ホスト(RHEL,Debian,Ubuntu…) からのrpm/dpkg の結果を集積するもモード。
  • vulsの紹介セッションで感じたこと
    自分でカスタムビルドしたパッケージは対応が難しそう。もっとお、RHEL./CentOSみたいな「特定のリリースに対してバックポートされたrpm」については話が変わるが。
    「中央管理サーバの」維持要員が確保しにくい場合は、マネージドプラン=futurevuls がよさそう。
    Server modeは、各マシンに日時ジョブでrpm統計を取ることで、資産管理(構成管理)にも使えるかも。ただアップデート適用まではやってくれないので、そこは「構成管理からのインシデント発行」みたいな流れで粛々とアップデートをかける必要がありそう。

参加して感じた板挟み

  • vuls/futurevuls はフリーミアムモデル
    今回はOSSとしてのvuls、マネージドサービスとしてのfuturevuls の紹介をいただきました。
    いまのところ、OSSとしてのvulsは表立った有償サポートはなさそう。特定の「こいつだけは構成管理しっかりしたい」みたいな崩されちゃ困る系の砦だけfuturevulsを契約して、慣れてきたら他の各ノードはOSSとしてのvulsを構成するとか、なのかなぁ。ノードが数十台までならマネージドサービス。100以上とかになったら各種自働化支援ツール(ansibleとか)を組み合わせつつ同社から業務支援/コンサルを受けるという形がよさそう。
  • …でも立場上提案しづらくね
    今回感じた板挟みはコレ。変な話、PDCAのPだけが繰り返される(年次脆弱性診断受けて、パッケージのxxが古いって指摘貰ったけどそれだけ対応して、また翌年までそのままにしとこう)現場ももちろん見てきた。本来はパッチ適用(月次週次アップデート)の半自働化ができればいうことはないのだけど、なにぶんトリアージがめんどくさくて年一回しかコンディションチェックをしない(まー健康診断だって年1でええやん?みたいな感じもあるが)企業も少なからずあるだろう。
    まあなんというか王様の耳はロバの耳案件なので言えないけど、色々アレがアレですよね…
  • 昔々のシェアウェア、もといドネーションウェアみたいなもんで、金額の多寡はともかく、おひねり?投げ銭?できるような仕組みがあればいいのかもしれないね。いや名前だけコンサル料とかやってるんだろうけど。
  • とにかく、派遣就業って立場だとお客さんに「このPG面白かった!やってみよう!守りたい砦だけだったらこういう方法でやれるっぽい!」と指金かますくらいがせいぜいだし。いち兵卒としては本籍に「これすごいんだから!ぜひ管理部隊でやってみて!」なんて口が裂けてもいえないわけで。この板挟み、なんとかしたいな…つら。

7/13 OSCNAGOYA

7/13はOSC NAGOYAに行ってきました。

はじめての立ち番

年末に参加したOWASP Nagoyaさんのブースで立ち番(紹介)をしました。OSCに一般参加することはあっても、立ち番は初めて。

「やべー、どうはなしてええのかわからん」

ふとISPを切り盛りしていたころのコテツ君が出てきてこう言った。

「ウェブサイトって、一国一城モデルじゃね?」

いいかえれば、家を建てる時の話。自分は家を建てたことはないけど、両親が新築したときを思い出すと、

  • 土壁塗るなり台風が土壁を全部ぶっ飛ばした (納期遅延)
  • 床がアリさんにやられたので床を張り替えたうえで換気系を見直した(脆弱性対応)
  • ホームテレホンがメーカ終売になったので買い替えた(EOL対応)

みたいな色々なイベントがあって、つまりウェブサイトは一国一城であって家を建てるのと一緒だね、と

ということで、OWASP TOP 10についても「家を建てるときの注意点」として紹介してみました。
ま、まぁリーダーが聞いたらコーヒー噴いちゃうかもだけどね!

  • XSS、アクセス制御の不備=上の例で言うところの白アリ
  • 既知の脆弱性のあるコンポーネント=ホームテレホンが終売
  • 不十分なロギングとモニタリング=ホームテレホン/ドアホンが記録機能ないぜ困ったぜ

まあこんな感じでTOP10 の各項目。家を建てるときの心がけみたいなものとして説明。
ていうかなんでいつもこんな比喩なんだろねコテツ君は(なるほどわからん…)

安全で丈夫な家を建てるノウハウとか、どんな時に白アリに狙われちゃうんだろ?みたいな話は海外(例えばアメリカ)の専門家が持ってて、それらを日本の利用者に分かりやすく説明をしたり、可能であれば日本語に翻訳しているコミュニティだよ、と
まあこんな感じで説明していました。

東京からいらしてた方には。ちゃ、ちゃんと、OWASP Japan Chapterをおすすめしておきましたよ(汗)

9月にはがっつりな勉強会が開催できそうなので、それはおいおい。(ま、まあリソースは僕が用意するわけじゃなくて,..けふん)

「どういう組織かより何を実現したい組織か、賛同者を増やす(結果的にはマネタイズすること?)には何をアピールすべきか。」

これ、直営なコミュニティだからこそすっごい刺さる。本籍の話を思い出したが、ここでそれを話すべきではないのでパス。

ともかく、2時間くらいの立ち番で、「直営なコミュニティでふるまうためにはどうすればよいか?」を自分なりに考える機会にはなって、本当に面白かったです。

あと、知り合いの方からいっぱい声かけてもらって、ついつい別件で話し込んでしまって「あれー本業に戻らねば!」って時がちょこちょこありました。みんなどうやってカバーしてるんだろ?またこれはおいおい。

チラシ周りも、あんまり考えてなかった…たぶん、「直営なコミュニティでのふるまい」を自分が意識してなかったからかなぁと。ホントは、 photon OS 上で juice shop と ctfd のdocker をそれぞれ動かして、「おー動く動く」できる1枚ぺらを作るはずだったんだけど…うん、できたらみんなに見てもらうよ。

他のブースを回る

立ち番だけしていてもアレなので、いろんなブースに遊びに行きました。

ISACA名古屋支部さんでのアレコレ

「あれ、コテツ君きょうそっちかねー」と某先生に声を掛けられて少し冷や汗が出たのはナイショ。ISACAさんの講演、最近はちょっとお休みしがちなのだけど、また頑張って参加しようと思う。

LPI-JAPANさんからもらったアレコレ

コンテンツは既存(LinuC=旧LPIC,CloudStack,OpenStack,PostgreSQL,HTML5)どおり。AWS/Azure/GCPの台頭で、昔ながらの「自社構内にサーバを置いての一国一城モデル」が若干崩れてきている感がありますが、そこをどうやってカバーできるかが落としどころになりそうです。今までの付き合い?からか、カナダLPIではなくEDUCO-Jに追随している企業(NとかFとか)があるのも事実なんですけどネ。

LPI日本支部さんからもらったアレコレ

LPIさんで色々面白い話を聞くことができました。かなりぶっ飛んだ隠し玉を持ってきた感じ。一国一城モデルは相変わらずですが、まあより今風な形にシフトしているのは確かです。

  • DockerやVagrantにフォーカスした認定試験
    DockerやVagrantにフォーカスした認定試験を教えてもらいました。今はまだ英語での受験ですが、もうしばらくすると日本語でも受けられるかも。確かに、LPIC1/2を受験したとき「あれ?lxcとかどうだっけ?」って不思議に思っていたんですよね。
    https://www.lpi.org/ja/our-certifications/devops-overview
  • BSDにフォーカスした認定試験
    現地で「のぼり」を見て「あれ???」って思ったのがコレ。
    2017年12月にさかのぼりますが、BSDCGとLPIの統合がアナウンスされていたもよう。ということは?LPIがBSDにフォーカスした認定試験を実施する予定とのこと。
    https://www.lpi.org/ja/articles/linux-professional-institute-and-bsd-certification-group-join-efforts
    BSDCG、日本法人としては BSD Research さんがあるんですね….うーん、この辺とのやり取りも気になりますが。
    https://www.bsdresearch.org/index.html.ja
  • LPIC LV3の改訂
    秋ごろをめどに、LV3が改訂されるとのこと。特に、304(仮想化+高可用性)が仮想化(KVM他+Docker)で1コマ+高可用性で1コマになるもよう。例によって並行期間が設けられて、その間は現行カリキュラムで大丈夫とのこと。まあとっとと合格しろってことだね。

いろいろあったけど、まとめ

半年間参加してみてようやくコミュニティへの参加の仕方?が分かった半日。

もちろんいきなりスタープレイヤーにはなれないので、僕個人のスキルパスやキャリアパス?も考えながら、どうアプローチすればこのコミュニティに利益(非営利組織に利益ってなんか変な表現かもだけど)が出るか、考えてみたいと思います。

netcatでそれっぽくsyslogを送ってみる

所用で、syslogサーバを作ることになった。しかもちょーたくさんのノードからsyslogが飛んでくるやつ!

Σ(‘A’;) い、いやちょーたくさんのノードっていくつだよ、ていうかdockerもlxcも、vitochaも知らないよ!

そうか netcatで偽装すればいいんだ(何)

材料

  • syslogサーバいっこ(rsyslogでもなんでも可)
  • Linuxマシンいっこ(Ubuntuでもなんでも可)
    +netcat ( centos の場合、yum install netcat とかそんな感じでOK)

手順 (CentOSの場合)

  • 適当にネットワークに参加する
    VMware ESXi 6 の上でCentOS7 をインストールする場合、 minimal.iso を使うとして、とりあえず内部的には VMXNET3 のドライバも入ってるみたい。下みたいに適当に入力して待っていればきっとOK (ネットワークアダプタは適当)
    ifup ens160
    yum install open-vm-tools
    yum install netcat
    yum update
  • 適当にセグメントを定義する
    ip addr (まず現状把握)
    ip addr add 192.xxx.xxx.xxx dev ens160 (揮発するけど ens160に落書きしちゃう。テストだし)
  • 実際にぶっぱなす
    > echo “<12> test ” | nc -u -w 1 -s 192.xxx.xxx.xxx 172.xxx.xxx.xxx 514
    対抗で tail -f /var/log/syslog (messagesかもよ) で待ち受けてると、UDPなだけに、対向に届いちゃいます。たぶん。
    もちろん、対向との間にまじめなfirewallがあれば遮断しますけどね。

気づき

  • syslog、普通に発行してもsyslogにはfacility/severity は表示されない
    特定のノードに facility/severity を変えながらバンバン試射する場合は、どれで着弾した、空振ったの確認をしないといけないので、
    上の例でいうと “test” って書いてるところにfacility/severity のテキストを書くようにしなきゃねー。
    https://www.amris.co.jp/netdocs/rfc3164_j.html (ARMISさんのRFC316t4の日本語訳。途中の表を参照)
  • ipアドレス大量に設定するのがめんどくさい
    がんばってやりましょう(シェルで)
  • facility/severity 切り替えるのめんどくさい
    がんばってやりましょう(シェルで)
  • 間違って他所に飛んだりしませんか
    飛ばさないようにするのが最低限のお作法です(ま、まぁ今回は自宅での簡単な検証ですし)

Node.jsを入れて消してみる (windows10のばやい)

とあるところの宿題で、Node.js をインストールして動作確認をすることになった。

今回は、ぱぱっとNode.jsをインストールして、アプリを起動して、そっと削除してみることにした。

お題

OWASP Kansaiさんが公開されてる、BadLibraryを使います。
https://owasp-kansai.doorkeeper.jp/events/72652

動かす手順

  • Node.js のv8をインストールする
    なんでも、v8を使うらしい。こまった。
    https://nodejs.org/dist/latest-v8.x/
    この辺の、node-v8.16.0-x64.msi を使います。まあWindows x64だからね。
  • BadLibrary を展開する
    https://github.com/SecureSkyTechnology/BadLibrary/
    に遷移して、「Clone or download」→「Download Zip」の順に遷移。
    「BadLibrary-master.zip」をダウンロード。
    展開先は、デスクトップでもよいみたい。(うごけば。うごけば。)
  • BadLibraryを実行する
    BadLibrary-master\src に遷移して、
    > npm install
    > node app.js -p 8080
    の順に実行。
    ブラウザで https://localhost:8080/ なんぞを指定してみると、うん、IDとパスワードを聞いてくるね。

削除する手順

全て逆にすればいい。(横着)

  • プログラムを終了する
    node を実行してるシェルで、男らしく ctrl + C を実行する。
  • アプリケーションの追加と削除
    男らしく、コマンドプロンプトから appwiz.cpl を実行する。
    「プログラムのアンインストールまたは変更」で、node.js ぽいエントリを選んで「削除」を押せばOK。
  • 残骸は削除
    badlibrary のフォルダを削除する。

気づき

  • appwiz.cpl まだ使えるんかい!
    Windows7とWindows10で色々呼び方は変わっているが、appwiz.cplは相変わらず「使える」ようだ。
  • なんかよくわからんけど警告がいっぱいでる
    アプリ内部で読んでるライブラリがアレみたいで、いっぱい警告が出ます。期限切れだからなんとかせーよ、ってことなのか。ま、まぁあんまり新しいやつだと、実装したい脆弱性がライブラリ側でふさいであったりもするんでしょうね。
    npm WARN deprecated hawk@3.1.3: This module moved to @hapi/hawk. Please make sure to switch over as this distribution is no longer supported and may contain bugs and critical security issues.
    npm WARN deprecated hoek@2.16.3: This version has been deprecated in accordance with the hapi support policy (hapi.im/support). Please upgrade to the latest version to get the best features, bug fixes, and security patches. If you are unable to upgrade at this time, paid support is available for older versions (hapi.im/commercial).
    npm WARN deprecated sntp@1.0.9: This module moved to @hapi/sntp. Please make sure to switch over as this distribution is no longer supported and may contain bugs and critical security issues.
    npm WARN deprecated cryptiles@2.0.5: This version has been deprecated in accordance with the hapi support policy (hapi.im/support). Please upgrade to the latest version to get the best features, bug fixes, and security patches. If you are unable to upgrade at this time, paid support is available for older versions (hapi.im/commercial).
    npm WARN deprecated boom@2.10.1: This version has been deprecated in accordance with the hapi support policy (hapi.im/support). Please upgrade to the latest version to get the best features, bug fixes, and security patches. If you are unable to upgrade at this time, paid support is available for older versions (hapi.im/commercial).
  • 業務端末にnodejsぶっこむのはちょっとこわい
    Windows 10の無印/Proの場合、CLient Hyper-Vするとかしない限り通常業務で使うインスタンスにnodejsをインストールする羽目になるので、そこの精神的負担をなんとかしたいよねーってのはあります。
    Linuxの場合、一旦docker/lxc、はたまたKVM/Xenでインスタンスを立てて、その中でnodejsいれて、curl でbadlibrary配置してーとかすればもう少し安全なんでしょうけど。そういえばMacOSとか大丈夫なのかな。
    → BWAやJuice Shopもそうなんだけど、なんとかdocker imageとかOVFを作る方法、確立したいねー。

付加価値のつく研修をちょっとだけ考える

付加価値とか多様性とかが最近ネタになるので、冗談半分ではあるけど、どんな研修があったらいいかを考えてみた。

大前提

「付加価値」の研修の場合、それをやらなかったからと、評価を下げることをしてはいけない。

応急手当講習

きた俺の出番来た(応急手当普及員)。
もっとも自分はレギュレーション的には2010年モデルしか更新講習では習っていないのだけど、社内で・町内で・コミュニティでやってと言われたら、たぶんやれると思う。
AEDなんてどこの就業先にもあるし。いつ倒れるかわからんし。俺が。(おい)

実際、変な話、変に酔って回復体位とか。採血で気を失って回復体位とか。救急隊員さん来るまで耐えながら回復体位とか。とりあえず回復体位覚えとけ、みたいな。
小さな傷に直接止血と絆創膏の役割を考えれば、「ああレジ袋は2枚持っておくと便利だね」ってなる。
人工呼吸マスクは、無理に用意しなくてもーではあるか。

発生しうるケースをEラーニングで振り返りできるようにしておけばよいよね。あとQ助いれとけ。

交通安全講習

運輸安全マネジメントをかじってたころに取り組もうとして、当時の職場ではいろんな方面の圧力で、実現できなかったもの。
所謂KYTだったり、「貨物自動車運送事業者が事業用自動車の運転者に対して行う指導及び監督の指針」の11項目だったりをEラーニングやPDF資料で配布して、特に意識する事柄を発表させるとか。
・・・あ、本籍は原則車通勤NGだったか。いや、社内福利厚生としての交通安全Eラーニング。あっていいと思うけどね。
運管のいる事業所ならともかく、個人運送業(スバルサンバー的な)の場合は、自分が知っている限りでは11項目の講習は必須ではなかった気がするが。かといってやっておいた方がいいはず。
旅客系案件は、やったことないからなぁ…でもスクールバスとかデイサービスの業界にはある程度需要がありそうな気はするんだが。あれ本籍に対する話だっけ。うっぷ。

情報せきゅりてぃ講習

なんつーか、ネタ的に一番難しいやつ。
どこまでレベルを調節するか。「安全な荷物の運び方」とかの物理的せきゅりてぃかもしれないし、ネチケット的なもの(どうやってメールをより確からしく送るか)かもしれないし。
安全なLINEの使い方、slackの使い方、iphoneの….(い、いやそれはベンダにきいてくださいよ)
確かに、その技術(プロダクト)を使った事案はあるけど、「公共の福祉」としてプロダクト事の対処法を講習として行うべきなんじゃろか、というのは結構悩ましい。
桜の代紋のお役所が特定のプロダクトの講習をやらないのも「ベンダロックイン対策」かなーと思ったりもしてる。
あんま抽象的にならない程度にはやってみたいかも、とは思うけど。

Linux/Windowsほか、特定のベンダ機能の講習

情報せきゅりてぃ講習に同じく。ベンダ固有な上に案件固有な話になりそう。個人的に苦手なもののひとつ。
言いたいことはさっき書いたので…すまない。

健康的な(ry)

住んでいる家と起きて寝る時間とご飯の味が違うから、これも一般論しか書けないよね。ま、まあ考えてみたいところだが。

まとめ

よくよく考えると「Eラーニング縛り」にすると結構難しそう。でも色々考えることはありそうで、ちょっとだけ楽しくなってきた。

対処を早めに打つということ

派遣先でsyslogサーバを触っていると、いろいろなものが見えてくる。
ファイアウォールのイベントログが妙に多いなーとか、仮想化基盤のストレージ起因っぽいやつとか。
はたまた、過去の変更作業の残骸が残ってたりして(げろげろー)
そこで、一個あるのが「対処は早めにうつ」ということ。

まずは報告する

とりあえず、課題は見つけたら報告する。もし、バグトラッキングシステムがあれば、チケットを起票したうえで上長へ口頭で報告する。
「前後のログの流量からなんかノードxxがおかしいんですけど、調べていいですかー」みたいな。
改めてそのノードのログについて調べて、「ただのログ肥大」「ただのログ減少」が、「バッチジョブ不具合」や「変更作業の残骸」とかだったら、BTSをその旨書き換えて、また報告。
まあ、予めBTSにどのタイミングで書くかは聞いておいたほうがいいんだけど。文化によっては、口頭のちBTSかもしれん。

参照した台帳は、ブックマークしておく

これはボクの趣味的なところもあるのだけど、参照した台帳は、情報カードなり、リフィルの一枚だったりに、「xxフォルダのxxにxx台帳があるよー」ってメモを書くようにしてる。
Windowsのショートカットファイルを作るとかの技法もあるんだけど。
構内でsharepointを使っていたら?sharepointの記事IDをブックマークに書いておけばよし。
また問い合わせがあったらブックマークを参照する。
もし、仮に参照したい台帳が(過去の経緯から)存在しなかったら、泣きながら台帳を起こして、上長に格納許可もらって、そのロケーションを周囲に共有して、ブックマークしよう。

変更作業が必要な場合は、早めにめぼしを付けて報告する

「これ手を打たないと毎日1GBとかログ生成されるですけどー、この規模で毎日1GBはちょっと増えすぎなのでなんとかしましょう」みたいな。きょーび1日1GBログが増えてもあんまり痛くも痒くもないと思うのですが、絶対に無視できるイベントを枝刈りするとかなら、まあ早めにめぼしを付けて、変更作業をしたい旨報告したほうがいいと思います。
塵も積もればなんとやら、ログの保持期間とか考えると、バックアップリストアやマイグレ等の大きな作業では地味ーにきいてきます。
…もし、はじめての試みになるなら、なおさら!今回は手作りの作業だけど、次回、次々回は今回の手順を活かして楽できるはずなので、早めに痛い目に遭っておきましょう(なにかおかしい)
軽症なうちに変更手順を確立しておかないと、あとでめんどくさい状態になったとき、「ちょっと荒療治すぎるな」でもっともっとやりづらくなります。

変更作業を行ったら、なるべく低い負荷で経過観察する

やりっぱなしで経過観察しないままだと、事象が悪化していることがあったとして、これに気付くことができません。
張り付きは無理だとして、例えばしばらくの間毎朝メールで通知するとか、slcak/ircが使える環境ならそこへメッセージを飛ばすとか。色々経過観察するためのネタはあると思います。
経過観察の自働化、大事だと思うけどね(なかなかできない)
もちろん、先ほどと同様、「一か所目の観察実績」があれば、「二か所目の観察」「三ヶ所目」…が設定しやすくなります。ここ大事。

まとめ

事象が軽傷杏うちに対処手順を実行して、観察手順も用意しておけば、あとあと「前回実績があるので、これでー」が言いやすくなります。風通しもよくなります。

…そーいえばコテツ君、部屋掃除は定期的にやっているのかい?
Σ(‘A’;) あ、えー、あのー