「監視は役割ではなくスキル」 by 入門監視

Mike Julian「入門監視」 オライリーを読んで、カルチャーショックというか、「我が意を得たり!」という思いをしたので、紹介します。

「監視は役割ではなくスキル」

私はソフトウェアエンジニア(Dev)に監視の知識は不要であり、 監視はインフラエンジニア(Ops)にお任せするものだと思っていました。 実際、これまでの職歴では、それで困りませんでした。

しかし、「入門監視」はこれを明確にアンチパターンだとしています。

ソフトウェアエンジニアはアプリケーションについて誰より詳しいので、素晴らしいアプリケーション監視の仕組みをデザインするには最高の場所にいるのです。

考えてみれば当たり前です。Opsはアプリの中身をよく知りません。 Opsが監視を任せられても、通り一辺の監視(CPU使用率など)しかできませんし、異常時にも自分で対応できないんです。

Opsが、

「CPU使用率が増えてるんですけど、大丈夫ですか?」

とDevに尋ねていたら「役割としての監視」に陥っている兆候です。

ユーザー視点での監視

「監視は役割ではなくスキル」を補強するのが、このデザインパターンです。

「監視」というとCPU使用率などの低レベルの指標がまず思い浮かびますが、 低レベルの指標は改善には役立たない、むしろノイズになってしまうことがあります。 です。

データベースサーバのCPU使用率が急上昇しても、ユーザーが影響を受けていないならそれは本当に問題でしょうか。

入門監視 P.30

「入門監視」では逆に「できるだけユーザーに近いところから監視を初める」ことを勧めています。

WEBサービスなら、CPU使用率より

  • HTTPレスポンスコード
  • レスポンス時間

の方が適切です。レスポンス時間が伸びていれば、少なくともユーザーが何か影響を受けていることはすぐに分かります。

「入門監視」では、さらにユーザーに(ある意味)近い部分の指標として、月次収支収益、顧客の解約数、アクティブユーザー数といった、ビジネスの指標も監視対象として挙げています。

今後は否応なしに、Devにも監視のスキルが必要になる

「そうは言っても、うちには優秀なOpsがいるし」と思う人もいるかもしれません。

しかし、最近はサービスを構築するときはクラウドがデフォルトの選択肢になっています。

クラウドでは物理サーバー構築が不要なので、Opsが他プロジェクトと兼任である、 あるいはOpsが不在のこともあるでしょう。

また、最近はインフラエンジニアが採用難であるそうです(AWSGCPなどのクラウドベンダーに引き抜かれてしまうので)。 となると、今後増々、

「DevだけのOpsが居ないチームがクラウドで構築する」

という体制が増えていくことでしょう。

そうなったら、監視を構築するのはDevのあなたです。

「入門監視」は全エンジニア必読

「入門監視」は228ページと、オライリーとしては薄めです。

監視とは何か、何をどんな監視するべきかという、プリンシプル・技術以前のところから説明しており、ツールの流行り廃りに囚われない本質的な知識を教えてくれる本です。具

定価3,080円と、大変お求め安い価格なので、ぜひ買って読んでください。

「権限の分離」をもっとよく知りたいと思う

私は最近「権限の分離(Segrecation of duties, SoD, セグリケーション)」について勉強し直したいと思っているのですが、 手近に良い本が見つからず、困っております。良い書籍や記事をご存知のいらっしゃったら、教えて下さると幸いです。

こんなことを言うのは、WEB業界で働いていると、「権限の分離」「権限の分離」っぽいものが混同されているとしばしば感じるのですが、 さりとて「権限の分離」を語れるほどの語彙も知識もなく、モヤモヤしているからです。

以下、自分なりの「権限の分離」とモドキの理解を書いてみます。

『権限の分離』

権限の分離(セグリケーション)
社員による不正や誤謬を防ぐために、業務を意図的に作り変えること。 1人に権限が集中しないようにしたり、監視役を設けたり、上司による決裁を必須にしたりすること。

『権限の分離』モドキ

権限の分離や不正防止に結果的に貢献することもあるが、貢献しないこともあるし、そもそも不正防止が目的ではなかったりするもののリスト。

上長決裁
特定の業務をする際に、上長による許可を必須にすること。 不正防止・事故防止の目的で行うこともあるが、上長がめくら判を押してしまい、機能しないこともしばしば。 どちらかと言うと、指揮系統の明確化・責任所在の明確化という意味が大きいのかもしれない。

職務分掌
業務を分担して行うこと・分担の仕方。2人以上で仕事をするには何らかの分担が必要になる。 分担を決める際には権限の分離も考慮することもある。

インフラ担当者とアプリ開発者の分離
大型コンピュータやネットワークなどのインフラを構築・運用するには高度な知識と人手が必要である。 よって、インフラを構築・運用する専門の担当者・専門の部署を設けることが多い。

データベースにおける権限階層
データベースソフトウェアでは、使用者の権限を「データの閲覧のみ可」「データの追加のみ可」「データやテーブルの追加削除も可」など、細かく権限レベルを分けて設定できる。データベースソフトウェアは、人間だけでなく別のソフトウェアからも利用されるので、ソフトが乗っ取られた場合の被害を防ぐため、細かい権限設定が重要である。もちろん、人間による不正や誤謬を防ぐためでもある。

SI業界における「開発」「運用」「保守」の分離
サービス開始時の開発、サービスの運用、運用開始後に見つかった不具合の修正や追加機能の実装(保守)を、別々の業者が請け負ったり、 同一業者でも別のチームが行ったりする。ぶっちゃけ請負業者側の大人の都合である。

開発者とテスト担当者の分離
開発者が自分が書いたコードを自分でテストすると、自分のミスを見て見ぬふりをしたり、視野狭窄に陥ったりして、テストが甘くなりがちだと考えられている。 よって、開発者とは別にテスト担当者を置いて、その人にテストさせる。

また、

  • 「開発者の給料は高いから、給料が安いテスターにテストさせるべき」
  • 「訓練を受けたテスト担当者(テストエンジニア)にテストさせる方が確実」

といった事情もある。不正防止に寄与する場合もあるが、主な目的はミスの防止である。

コードレビュー
開発者が書いたコードを、別の添削者が添削すること。不正を抑止する面もあるが、どちらかというとミスを見つけたり、コードのより良い書き方を指導するのが目的。添削者は1人の場合もあれば複数人の場合もある。

ペアプログラミング・ペア作業 1人でもできるプログラミングや作業をあえて複数人で行うこと。目的は色々あり、

  • 3人寄れば文殊の知恵(2人だけど)
  • 目玉が2個より4個の方がミスも見つけやすい
  • 別途コードレビューする工程を省けて効率的
  • ベテランと新人を組ませることで知識の伝承ができる
  • サボリを防げる

機長と副操縦士
現在の航空機は自動化が進んでいるので1人でも操縦できるが、2人の操縦士を乗務させるケースが多い。 パイロットが航空機を盗んだり、乱心して故意に墜落させるのを防ぐためである。 もちろん、操縦士が急病で倒れた場合のバックアップや、トラブル発生時に分担して対応するためでもある。

江戸時代の武士における「相役」
江戸時代には1つの役職に複数人の武士を配置することがしばしばあった。不正防止という意味もあったのだろうが、武士が余っていたという面もある。

世界で0.1%の花

私が中学生のころに「世界に一つだけの花」という歌が流行りました。

一つとして同じものはないから NO.1にならなくてもいい もともと特別なOnly one

といった歌詞が当時の世相にマッチしたようですが、「NO.1を目指す中でこそOnly one になれるんだ!」なんて反発する人もいました。

私も、偏屈だったので、「確かに人はOnly oneだけど、人より優れていないと意味ないよなぁ。俺だって歌は歌えるけど、SMAPみたいにCDを出せるわけでもないし」と思ったものです。

しかし、大人になってちょっと考えが変わりました。

続きを読む

エンジニアの説明下手は「知識の誘惑幻惑効果」のせいかもしれない

ちょっと前、こんな記事が少し炎上していました。

説明が分かりにくいのは知的怠慢だ、技術者よ思い上がるな | 日経 xTECH(クロステック)

https://tech.nikkeibp.co.jp/atcl/nxt/column/18/00148/100300081/?n_cid=nbpnxt_twbn

「エンジニアの説明下手」については、

続きを読む

「日本人には名字がある」ことへの素朴な疑問

お盆に親戚廻りをすると、我が家の名字の歴史を聞かされることがあります。我が家は江戸時代は別の名字だったが明治時代に変えたとか、市内の同姓の電気屋と美容院は親戚ではないが縁があるとか。

ところで、ネット上で

江戸時代の庶民も、公には名乗れなかっただけで、みんな名字を持っていた

という説を見ることがあります。これは本当なのでしょうか?

続きを読む

About me

東京在住のプログラマーです。

プログラミング関連の話題を投稿しています。

最近は、実務的な話題はQiitaや勤務先のブログの方に投稿しており、こちらのブログにはプログラミングに関係ない思いつきが多くなっております。

なぜサードパーティ・ライブラリを避けるべきなのか?

例えば Pythonには標準ライブラリに urllib.requestというモジュールがありますが、高機能なサードパーティ・ライブラリである requests が普及しています。

しかし、私は先日あるプロジェクトであえてrequestsではなくurllib.requestを使うことを選びました。友人にそれを話すと少し驚かれましたが、私は以下のような理由から、場合によってはサードパーティ・ライブラリは避けるべきと思っています。

続きを読む