銀色うつ時間

思い出すたび何か胸につっかえてるだけ

マネジメントは難しい

書評 マネジメント

マネジメントは難しい。

得体の知れないプロジェクトという怪物に対して、有用なアプローチを見出し、いかなる手段を用いても遂行しなければならない。考えるべきことは山ほどある。プロジェクトのスケジュール管理、非エンジニアとの企画検討、要件のヒアリング、仕様策定。差し込まれる割り込み案件、実装すべき機能のタスク化、ブレイクダウン。設計・コードレビュー、チームの技術力底上げ、メンバのモチベーション管理、その他雑用、ドサ回りに至るまでもがマネジメントに含まれる。

『Team Geek』を読んで共感する部分もあったが（HRT原則は本当に心がけるべき）、違和感を拭えないのは、メンバを「信じて、任せるべき」であるとする部分だ。チームとしての総合力が突出して高くない且つスケジュールがタイトな現場に於いては、これは当てはまらないと感じている。

マネジメントには頭と時間を使う。仕様策定やアプリケーションの設計など、考えるべきことは山積みであり、これらに考慮漏れや曖昧さが含まれると、プロジェクトは滞り、メンバは曖昧な要求に対して不満を持ち、最終的な成果物の価値も落とす結果になる。マネジメントを行う者は「考える事」と「論理的思考に基づき決定すること」に頭と時間を可能な限り費やすべきだ。また、睡眠不足や疲労が蓄積している場面では、適切な判断が下せないので、自分は手を動かさず、極力休息を取る必要がある。マネジメントと実際に手を動かす作業をそれぞれ充分に遂行するのは、非凡な人材にしかできない。ので、「信じて、任せるべき」なのである。

しかし、それではうまく回らない。プロジェクトに対して、決められた納期（あるいは、求められるスピード感）で曖昧な要件の中で仕様を固め、品質のよいコードを書くことができる人間ばかりではない。むしろ、自分も含め大抵の人が充分にそれをこなすことができない。原因は無数に存在する。曖昧な仕様を積極的に解決しない、スケジュールを意識せず永遠に設計について思案する、そもそも要求を満たしていない、エラー処理など、考慮漏れがあまりにも多い、等。

「ただ単にお前が無能なだけではないか」といった意見はごもっともである。これらは、冒頭で挙げたマネジメントが全て解決する。メンバ個々人の性質に応じて、仕様を細かく固めてから依頼することであったり、当事者意識を持たせるためのモチベーション向上であったり、経験不足や細部の曖昧さをテストコードを書かせることで補ったり、等のアプローチが考えられる。だが、同時に複数ラインで様々なことが進行する中で、全てに対して適切な処置を施し、判断を下すことは中々に難しい。毎日、気がつけば深夜だ。

マネジメントする者自身が充分な実力をつければ、様々なことが解決する。必要なのは、自分の頭が充分に冴えたコンディションを維持できる時間を確保することだ。仕様決定や設計は、論理的思考とソフトウェア設計の知識および経験を培えば時間は削減できるし、数時間かかるようなコードレビューも、テスト環境が充分に整備されていればコードレベルのバグ等は担保され、人間が気にするべき設計や要件を満たしているか、といった部分に注力できる。しかしながら、中〜大現場なソフトウェア開発の現場では、古いライブラリや複雑なコードに縛られてそういった改善を行うのが大きなコストになっていたり、次々に来る要望と既存システムの保守運用に対応するのに精いっぱいだったりして、中々うまくいかないのも現実である。そういった事情の上で、「信じて、任せる」ことができるのなら喜んでお願いするのだが、実際には厳しかったりする。

故に、結局は自分の手を動かすことで解決する。

これは純粋に人が足りない、ということの証左でもあると思うが、「人が足りない」という言葉の裏には一部甘えだったり、自分の未熟さを認めるような響きを感じていて、敗北感を感じる。簡単には音を上げたくない、といった個人的心情もあるのかもしれない。また、コードを書く時間を確保したい、という心情もそれに交錯する。弊害として、作業内容が曖昧なままだったり、仕様の考慮漏れなどが発生して、メンバの作業を停滞させるし、今ひとつチームの開発効率が高まらない結果を産む。

結局のところ、問題はマネジメントする者自身にあるのだろうと思う。適切なマネジメントと、コードを存分に書くことは両立しない。両立させるためには、頭と時間、確かな技術力が全て必要なのだ。それを持たざる者は、コードを書くことを優先してはならない。プロジェクトを成功に導くことが至上命題だからだ。しかしながら、自分がマネジメント専業となるには、まだ早過ぎる。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

いまレンタルサーバ・クラウド契約するなら

ほぼ放置状態だったさくらのVPSを解約した。年間契約だったので、解約するタイミングがなかなかこなかった。ドメインだけ手元に置いてあるので、これを機にクラウドサービスを色々使ってみようと思っているんだけど、どこがよいのだろう。EC2かdigitaloceanが取り急ぎ無難な気もするけど。

mysqlコンソールでプロンプトを変更する

MySQL

mysqlコマンドの出力結果を貼ったりするときに、見る人に「このサーバ内での作業なんですよー」みたいなのを示しておきたかったりする。もちろんデフォルトは以下

mysql>

そういうときはPROMPTを使うとよい。作業日時やログインユーザ、ホスト名などの表示変更が可能だ。例えば作業ユーザとホスト名を指定したい場合は以下。

mysql> PROMPT \u@\h >

>とスペースを最後につけておいた方が個人的には見栄えがよい。 プロンプトは次のような表示となる。

user@database01 >

以下はよく使うシーケンス。

\c
カウンタ。複数のSQLを実行する場合にナンバリングに使える

\D
日時

\u
ログインユーザ名

\h
ホスト名

特定のプロンプトを毎回打つのが面倒なので、その場合は$HOME/.my.cnfにPROMPTを設定しておけば、デフォルトで設定できる。

Ansibleで冪等性を保つためにはfailed_whenとかstatを使うと便利

ansible

構成管理ツールとしてAnsibleを使って開発環境を作っているんだけど（本番でも使えるようにとかはまだできてない）、特定のコマンドの実行結果によって次の処理をスキップするかどうかみたいなのを制御したい場面がある。

例えばcentos6.xでnginxの設定を行いたいとすると、以下のようになる。

- name: get nginx rpm
  get_url: url="http://nginx.org/packages/centos/6/noarch/RPMS/nginx-release-centos-6-0.el6.ngx.noarch.rpm" dest="/var/tmp/nginx-release-centos-6-0.el6.ngx.noarch.rpm"
- name: add nginx rpm
  yum: name=/var/tmp/nginx-release-centos-6-0.el6.ngx.noarch.rpm state=present
- name: install nginx
  yum: name=nginx state=present
- name: register service
  service: name=nginx enabled=yes
- name: add conf file
  copy: src=../files/extra.conf dest=/etc/nginx/conf.d
- name: move default conf
  shell: mv /etc/nginx/conf.d/default.conf /etc/nginx/conf.d/default.conf.backup

確かにこれでもnginxのインストールと必要な設定は行えるが、このままでは冪等性が担保されない。Ansibleのコアモジュールの多くは冪等性をチェックしているが、shellモジュールなどの冪等性は担保されない。対象のサーバに対してこのスクリプトを実行した場合、2回目移行もdefault.confをmvしようとしてエラーになるだろう。

幸いAnsibleにはregisterという出力を変数に格納できる仕組みがあるので、それを利用するとよい。

- name: is nginx already installed
   shell: which nginx
   register: which_nginx

# （中略）

- name: move default conf
  shell: mv /etc/nginx/conf.d/default.conf /etc/nginx/conf.d/default.conf.backup

しかし、これではエラーとなってしまう。Ansibleは終了ステータスが0以外のものを原則エラーとして解釈するからだ。which nginxでnginxが存在しなかった場合、no nginx foundのようなものがエラー出力に出てしまうから、ハンドリングする必要がある。

結果、以下のように書くのがよい。

- name: is nginx already installed
   shell: which nginx
   register: which_nginx
   failed_when: which_nginx not in [0, 1]

# （中略）

- name: move default conf
  shell: mv /etc/nginx/conf.d/default.conf /etc/nginx/conf.d/default.conf.backup
  when: which_nginx.rc == 1

failed_whenは値に記述した結果のBooleanでタスクの成功可否を判定する。failed_whenを使うことで終了ステータスの正常・エラーに関わらずタスク自体は通過させ、以後はそこで宣言した変数のステータスや出力内容を見ながらタスクを実行するかスキップするか決めるようにするとよいと思う。

余談だが、特定ファイルの存在確認をするためには以下のようなやり方がある

- name: check default conf
  stat: path=/etc/nginx/conf.d/default.conf
  register: is_exists
- name: move default conf
  shell: mv /etc/nginx/conf.d/default.conf /etc/nginx/conf.d/default.conf.backup
  when: is_exists.stat.md5 is defined

statモジュールを利用して変数にset、md5のハッシュ値が存在するかどうかで以降のタスクを制御する。

インフラエンジニアの教科書読んだ

書評 infrastructure

インフラエンジニアの教科書

インフラエンジニアの教科書

読んだ。業務でアプリケーション開発をしているだけでは分からなかった領域を知れてよかった。以下のようなトピックをざっくりと解説しているが、ちゃんと頭の中に収めるには他の本を読んだりやれる領域は実際に手を動かしてみる必要がありそう。

サーバ

  • タワー型・ラック型などのサーバの種類
  • SATA・SAS・SSD等ストレージの種類
  • 仮想化技術・ハイパーバイザなど
  • RAIDで行う冗長化とパフォーマンス向上の戦略

ネットワーク

  • ルータの役割
  • L2/L3スイッチ
  • L4/L7スイッチ（LB）
  • ネットワーク構成の構造（front/back2層・3階層構造・ネットワークファブリック）
  • OSI参照モデル

ストレージ

  • ローカルストレージ・外部ストレージ・ホットスペアなど
  • 外部ストレージを利用したディスクI/O性能の向上
  • シンプロビジョニング（容量の仮想化）

DC

  • DCの選定（拡張性・地理的要因・空調など）
  • ネットワーク機器の配置・エアフローなど

障害対応

大規模インフラ

  • 資材調達
  • CDN
  • DSR構成による負荷分散（L4スイッチを上位スイッチに直接接続することで捌けるリクエスト量を増やし、ネットワーク構成の自由度を上げる）

広範囲な領域をざっくりと説明しているだけなので、ひとつひとつの解説が薄い感は否めない。インフラエンジニアのお仕事案内としてはよいかもしれないけど、業務レベルとなると全く太刀打ち出来ないという認識を持ってもう少し詳しい解説をしている書籍を読む必要がある。今度はネットワーク構成についてや高可用性が求められる場合におけるアプリケーションのシステム構成、要求性能の算出からハードウェアを選定する技術などを学びたい。

ある光

実家の愛犬、ごんたくんが旅立ってしまった。

12月の頭から調子が悪くなり始めて、1/20の未明にあっさり逝ってしまった。心臓病だった。13歳と3ヶ月だった。

12月に調子が悪いという報告を聞いた日、偶然なのかお告げなのか分からないけど、僕はたまたまごんたくんの夢を見ていて、ちょっと嫌な予感がしていたところに本当に知らせがきてびっくりした。会えるのが最後になるかもしれないと思い年始に帰省したのだけれど、痩せてはいたものの思ったより元気そうだったので一安心していた矢先だった。「遺影撮っておかなきゃ」なんて冗談交じりに言いながらカメラを向けていたけど、まさかそれから3週間で本当に死んでしまうなんて正直思っていなくて、今も現実感がなかったりする。年末年始は仕事関連でも色々あったので悩んでいたけれど、帰省しておいて本当によかった。最後に、頭を撫で、ジャーキーをあげて、 一緒に散歩することもできた。

いつも母が仕事から帰ると小屋から出てきて喜ぶのだけど、それが出てこなくなって、2日後のことだったらしい。その日は夜中まで母親についてもらっていて、翌朝様子を見てみると、眠るように死んでいたそうだ。最後まで大好きな母に撫でてもらって、ごんたくんは幸せだったと信じたい。

誰かを噛んで怪我させたことなんで一度もないし、初対面の人でも決して吠えたりしない優しい犬だった。いつも家族に対して愛想よく振る舞って、僕と散歩するときは飛び跳ねて喜んだりしていた。芸は待てとお手と伏せくらいしかできなかったけど、僕はそんなごんたくんが好きだった。

元々は、おばあちゃんの家で飼われていた犬に子どもが産まれてしまったという田舎ではよくある話で、引き取り手が必要になって我が家にやってきた仔犬だった。僕が13歳のときだ。妹が大事そうに抱えていたその雑種の仔犬は、突然別の場所に連れて来られて不安そうな表情をしていたのを、よく憶えている。寒い冬の日の夕方、一緒に歩いた道すがら、ごんたくんが立ち止まって、僕も立ち止まって、遠州のからっ風が吹いた時、空は美しい赤で、ああ、僕らは心が通じていると感じた（犬を飼う人のいくらかは分かってくれると思う）こと、多感な時期に色々悩んで、ナンバーガールだとかフィッシュマンズなんかを聞きながら何も言わない少年の側にいつまでもいてくれたこと、上京してからあまり帰省したかったけど、ごんたくんは僕のことをちゃんと覚えていて、帰省する度に喜んでくれたこと。そんな思い出の断片が、僕の身体の中で跳ねっ返る。

1/19は妹の20歳の誕生日で、もしかしたらごんたくんは妹の成人を見届けるまで頑張ってくれたのかもしれない。

夜になるとごんたくんを思い出して、泣いてしまう。こうして文章にすると、僕は自分でもびっくりするくらいごんたくんが好きだったということ、ごんたくんと過ごした日々がいかに素晴らしいものだったかということに、改めて気付かされる。

ごんたくん、大好きだよ。今までありがとう。

f:id:sisidovski:20131215091835j:plain