2015-11-18

システム構築時のホスト名の命名方法について

一時期検討したのでメモ。

議題

自由にネーミングルールを決定できる場合、以下の用に名前付けすると効率がよいと思われる。

[システム名][サイト名][サブシステム名][役割][連番]

例：TEMSDB001

TE システム名(TESTシステム) M/Sサイト名(Mail/Sub) S ミドルウェア名(SQL) DB 役割(DBサーバー) 001 連番

検討ポイント

名前を正規化し、スクリプト等で扱いやすくする
アルファベット順で並び替えた際、構築対象サーバーがひとまとまりになるようにする
人間がそれなりに呼びやすい名前とする

以下、その他検討したケースとダメな理由をメモ。

まず、どのような要素を"名前"に含めるかどうか。趣味のサーバーでなければ、分かりやすく管理しやすい名前がよい。

(星座の名前とか競走馬の名前は研究室のサーバーで十分)

必須要素

サーバーの役割
- さすがに必須である
連番
- 同一役割のサーバーを複数台構築するのがほとんどなので必須。
システム名
- エンタープライズシステムの場合、他部署が管理しているシステムと区別するために必要
ロケーション名
- 一昔前なら不要だが、サーバーのサイトを分けて構築するケースが増えてきたので必要と思われる。
  - 無くてもよいが、メインサイトのサーバーだけ処理する、IPアドレス採番時に気づきやすい、などメリットが多い
ミドルウェア名 -サーバー台数が多い場合、システム名+役割+連番では上手く命名できない事が多いので、含めておくと後で助かる場合がある

不要要素

OSバージョン
- 一度構築したサーバーのOSをアップデートして使用するケースは少ないが、サーバーに付与しても何の情報にもならない
  - WindowsかLinuxか程度なら有用だが
製品名
- 吸収合併の多いIT業界で製品名を付けると、何年後にはサーバー名と製品名称が不一致になっている可能性がある。
  - 悪い例：VERITAS Backup Execなので"V" → Symantec Backup Execになっちゃった…。
  - 良い例：役割がBackupなので"B"
プロジェクト名
- つけがちだが、数年後にサーバー増設プロジェクトが発生した場合、同じ役割のサーバーの命名ルールが分断される。

要素の命名順番

サーバー名をアルファベット順に並び替えた時にどうなるかに着目すると、システム名を一番最初に持ってくるのが良いと思われる。良くあるのがサイト名を最初に持ってくるシステムだが、こうするとGUIでアルファベット順に並び替えた時に同じシステムの同役割のサーバーが分断されてしまい、作業ミスが発生しやすくなる。全部CUIでやるからいい、という人もいるかもしれないが、月次レポートなどでExcelでデータ出力する際に、同じ役割のサーバーが別々で表示されるのでストレスがたまると思う。

2015-11-08

プロジェクト終了時の振り返りについて

プロジェクト終了時の振り返りは絶対にやるべきであり、かつ他の改善取り組みに比べて意識的に促進するメリットが大きいと考えます。

プロジェクト振り返りをやるべき理由

3，4か月～半年間の時間をかけて取り組んだ仕事なら、いろいろな経験を得ているはず。
その経験の人は忘れます。
なので、文章として記録しておく

愚者は経験に学び賢者は歴史に学ぶ、と言いますが、経験から学んじゃダメというのではない。むしろダイレクトに自分の血肉となるので整理して吸収すべき。

プロジェクト振り返りを促進するメリットが大きい理由

他の業務改善案と違い、放っておくと誰もやらないから

例えば、提案活動効率化や構築作業のミス防止などは直接的に業績に影響するので、公式な施策として実施されやすい。一方振り返りを促進してもすぐにメリットが出るわけではないし、出たとしてもメリットが見えにくい。だからこそやる意味があり、やることで0を10や100に出来る。

振り返りの進め方(僕の場合)

プロジェクトが終了した時点でプロジェクト全体の振り返りをする場合。

振り返りシートを用意し、プロジェクトのフェーズ毎に振り返りを行ってもらう
- プロジェクト終わったタイミングでは直近のフェーズしか覚えていないため
フェーズ毎に、良かったこと・悪かったこと・続けたい事を書いてもらう。
プロジェクトのイベントやマイルストーンを記載したカレンダーを渡す
- プロジェクト前半を思い出してもらうきっかけとして
- このカレンダーには印象深いと思われる事柄は何でも記載する
  - 例：歓迎飲み、他チームのトラブルに巻き込まれる、など

あくまで僕のやり方です。ただ、プロジェクトのカレンダーなどを提示し、思い出す手助けをする必要はあると思います。

忙しければ振り返りシートを書かなくても大丈夫、と伝えています。シートに落とさなくても振り返り会の時に思い出せればそれでいいからです。ただ、シートに書くことで事前に思い出してもらうことができるので、今後どうするかは悩み中です。振り返り、という文化が定着してくれば強制もしやすいのだけど。

振り返り中

コーヒー飲みながら思い出話をするような進め方をしてます。あんなこともあったよね～こうすればよかったね～、みたいな。

振り返り後

振り返り会で出た意見を必ず何かのドキュメントに纏め「結論」として提示する
- 後から見返す場合、分かりやすい結論がまとまっていた方が見やすい

これが一番重要で、振り返り主催者は振り返り会をやった事で"終わり"と思いがちですが、参加者に「次も振り返り会をやろう」と思ってもらうためには、振り返り会はメリットがあるんだ、と感じてもらわなければいけない。振り返り会でプロジェクトの記憶も蘇っていい点・悪い点を洗い出せたとして、数年後に見返したときに"結局、次はどうすればよかったんだっけ?"となります。

「結論」では必ずしも白黒つけなくていいです。振り返りで意見が分かれた場合、「結論」には"次も大きな問題となる可能性があるため、事前に議論しておく"とかでもいいと思います。とにかく生の振り返りシートだけで結論付けたと思わない。必ず別のシートを作成する。

2015-10-22

powershellからyammerにアクセス(yammer REST API)

そんなわけではてなブログに技術メモを書きます。

Wordpressで慣れているので、記法はmarkdownを選択。

あとpowershellでシンタックスハイライト効かないので、以下記事を参照にする。

WordPress.com からはてなブログに移行した理由と移行作業 - tech.guitarrapc.cóm

ちょっと用事でyammerのデータを取得する必要があったので調査。yammerはAPIを提供してくれているのでそれ使えばよい。

developer.yammer.com

RESTでのアクセスとなる。

昔、rubyでfacebookやtwitterのデータを取得していたがそれはrubyの便利ライブラリを使ってのことであって、REST APIを生で使うのは初めてであるので'yammer rest api powershell'で調べた結果がこちら。

blog.kloud.com.au

結論から言うとこの記事の通りにやってデータを取得することができた。

…という記事だけだと寂しすぎるので、少し解説。

1. yammerアプリケーション登録

プログラム以前の問題として、yammerにアプリケーション登録し、クライアントIDと秘密鍵を発行してもらわないといけない。

(本人)yammerにアプリ登録
(yammer)クライアントIDと秘密鍵を発行
(本人)REST API経由でアクセス(クライアントIDと秘密鍵でトークンを作成)
(yammer)クライアントIDと秘密鍵(実際はトークン)を照合し、正しいリクエストであることを確認してデータを返す

なんでこんな事するかってーと、REST API経由でのアクセスをyammer側で管理するため。例えば1秒間に100回リクエストを送ってくるクライアントIDは一時的にアクセス不可にするとか。同等の仕組みはfacebookやtwitterにもあります(よくAPI制限がどうたら～ってのはこの事)

アプリケーションの登録はこちらから↓

https://www.yammer.com/client_applications

'アプリ'といっても実際WebアプリやiPhoneアプリを作るわけではないが、REST界隈ではそういう言い方をします。名前は適当に作ってclientIDと秘密鍵をゲット。アプリの名前などを変えたければ新規アプリを登録して、そちらのclientIDと秘密鍵を使えばいい。

2. 認証コードの取得

clientIDを使って認証コードをゲット。

以下のようなURLにアクセスすれば認証コードをゲットできる。

https://www.yammer.com/dialog/oauth?client_id=$clientID&amp;redirect_uri=$RedirURL

powershellでやる場合はこちら。

$clientID = "xxxxx"
$clientsecret = "xxxxx"
$RedirURL = "https://www.yammer.com/xxxxx.com"
 
$ie = New-Object -ComObject internetexplorer.application
$ie.Visible = $true
$ie.Navigate2("https://www.yammer.com/dialog/oauth?client_id=$clientID&amp;redirect_uri=$RedirURL")

# この時点で秘密鍵は不要

そうすると、

http://www.xxxxx.com/?code=xxxxxxxxxxxxxxxxxx

みたいなページに飛ぶ。ここのcode=xxxxxxxxxxxxxxxxxxが認証コードになります。

3. 認証トークンの取得

認証コードが分かったら

clientID
秘密鍵
認証コード

の3点セットがそろうので、以下のページにアクセスして認証トークンをゲット。

https://www.yammer.com/oauth2/access_token.json?client_id=$clientID&amp;client_secret=$clientsecret&amp;code=$Authcode

powershellで書くならこちら。

$ie = New-Object -ComObject internetexplorer.application
$ie.Visible = $true
$ie.Navigate2("https://www.yammer.com/oauth2/access_token.json?client_id=$clientID&amp;client_secret=$clientsecret&amp;code=$Authcode")

4. APIにアクセス

適当な場所にダウンロードしたトークンをパースして、認証ヘッダーに含めてAPIにアクセスします。

$Openjson = $(Get-Content 'C:\Tokens\access_token.json' ) -join "`n" | ConvertFrom-Json
$token = $Openjson.access_token.token

$uri = "https://www.yammer.com/api/v1/messages.json"
$uri = "https://www.yammer.com/api/v1/search.json"
     
$Payloadjson = '{
"search": "test"
}'
 
$Headers = @{
"Accept" = "*/*"
"Authorization" = "Bearer "+$token
"accept-encoding" = "gzip"
"content-type"="application/json"
}
 
Invoke-RestMethod -Method Post -Uri $uri -Header $Headers -Body $Payloadjson