Kinde本が50%オフ祭りだったので「DevOps教科書」を買って第１章だけ読んで気づいたメモ
Kindle本50％オフセールがやっているので、気になってたdevops教科書を買ってみた。
とりあえず第１章だけを読んだところでの気づきがツイートしたとおり、幾つかあった。
ツイートしたけど、devopsの定義で、なんで「devopsは高品質の」と「高」をつける必要があるのだろうね。品質は満たしてるか、未達のいずれかなんですよ。高い品質ということは、品質を超えているという意味でしょう。過剰な品質は金メッキなんだよ。あと、品質未達の状態で要求されている品質に近づけることに高品質とは使わないよね。
「コミットからデプロイまでの期間短縮を目標とした活動の実践がdevops」なのはオーケー 。わかりやすい。
「コヒーレントユニット」って使わない言葉だけれど、ちょっと知っている言葉。Oracle Coherence ね。インメモリーのソリューション。それで知ってた。で、コヒーレントは一貫性のある単位…。言葉としては使ったことないですねー。
やくわりなんだけど、チームリーダの役割が仕事を捗らせるのは当然として「日程策定はチームで」ってところの感覚に違和感持たないようにしないといけないのかなぁ。この辺はアジャイル開発だと普通なんだけどね。
サービスオーナーの仕事もわざわざ別にロールをつくつ必要があるのか、と思いつつ違和感ありあり。それ、リーダの仕事でいいじゃん。だって対外折衝役なんでしょう、と思うので。それを兼務できないほどチームリーダの仕事はしんどんだっけ。そうするとウォーターフォールのプロマネはスーパーマンになってしまうのでは。やはり、期間の短さは並行でやらないとだめなのかなぁ。
花形は、信頼性エンジニアぽいですね。でもでも、障害対応するエンジニアってレベル高いシステムエンジニアですよね。生姜切り分けとか原因の可能性をしないといけないから、そうした実践知と形式知を持っていないと切り分けできないわけで。
「カナリア」は先行デプロイするノードに先行リリースするということなんでしょうね。こういったお試し的というか毒が入っていないかを試すのにカナリアって使うイメージだけど、それをシステムに当てはめるのってどうなんだろう。
devopsエンジニアの職務は「ツールに眼を光らせ、インプットを与えること」と。まあツールを知って性能をフルに引き出せないといかんわけで、それがツールに目を光らせるなんだよねえ。あと、とっても当たり前だけど、生産するのがエンジニアなのでエンジニア自身がインプットの主体であることを書いていあるのは良いと思う。
と、書きつつ、個人、チーム、全社とレベルで運用を考え、守れを言ってるところが割と高度な要求をしているな、これ。一体どのくらいシステムエンジニアで運用まで考えて規律を作って守れるんだろう。この１点だけでも要求レベル高いワー。devopsエンジニアって。
あと、さらっと「リソースはアーキテクチャによって管理され、決定される」とあるんだけどね。これ、方式設計するときに論理ばかりじゃなく物理も（仮想かもしれないけれど）やるんだよということでいいよね。その中にはランニングで困らないようにしておけ、っていうのも入っていそう。
書く方は気持ちいいだろうけど、これ、やる人はしんどいね。
kindle本でdevopsを検索したリンクはこっち（50%オフ以外も混ざっているので注意） → Kindle本からDevOpsで検索
