@hihihiroroのLog

ダラダラと。本ブログは、個人の意見であり、所属会社とは関係がありません。

202111 振り返り

具体的になにがあるわけではないのだがなんか忙しいし疲れている気がする。今までよりも睡眠時間が長くなっているのだが、疲れているわけではなくただ冬眠の準備でも始まっているのだろうか。
部屋を片付ける機会があったので少しだけ部屋がキレイになった。今までそのまま床やテーブルに置いていたものを棚を買ってしまったのである。それだけでも見栄えは驚くほど変わるものだなと思った。しかし、それでも本が入っているダンボールが14箱ほどあるのでまずはそこをどうにかしないとだな。

べんきょうかい

今月は何もでなかったな。
社内の勉強会には参加したがそれくらい。社外の人ともしゃべること少なくなったしもう少し活動してみよう。

ほん

ライトノベルも含まれるが小説を久々に数読んだ。
仕事場の人が入れ替わったり、他部署の人と話す機会が増えて自分の勉強不足をよく思い知る。
すこしでも勉強しておかないとなと思って来月以降はもっと頑張りたいところ。

えいが

ソードアート・オンラインは来場者特典につられて2回目観に行ってしまった。面白かったので悔いはない。
土竜の唄ときのう何食べた?は映画を見に行くために毎夜ストリーミングで既存の分をみてから観に行った。どっちも面白かったな。
エターナルズはマーベルはやはり好きだなと思って帰ってきた。

ぶろぐ

インフラや運用周り。
今の仕事メンバーの中でまだ知識やとしてはこのあたりが自信もてそうなので。

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

「運用改善の教科書」を読んだ

運用設計の教科書 を読んでいる最中に出ていることを知って買ってはいたが積読していた。運用は長くやっているので興味のある分野でもあるので読んだ。

運用設計の教科書 のブログはこちら

hihihiroro.hatenablog.com

本書の目次は以下。

1章 運用の変化と運用改善の目的
2章 運用ルールを見直す
3章 運用を分析して改善する
4章 自動化とツール
5章 クラウドサービス運用に必要なこと
6章 運用に置ける情報セキュリティ対応
7章 運用チームに求められるスキル
8章 運用改善が評価される組織づくり
Appendix1 運用改善と心理的安全性
Appendix2 運用のアウトソース
Appendix3 参考資料

前半では改善の進め方を、後半では改善するために必要な要素について説明されている。
1賞から3章までが前半になっている。この中では運用改善は生産性の向上が目的で、運用改善のゴールとして継続的に運用改善ができる組織ができることと説明されている。
システムだけで運用を考えるのではなく、サービス全体をまとめて考えて運用することが推奨されていて、なるほどと思った。運用作業でシステム単体に影響があるものはやっていても少なく、そのシステムが使われるサービス全体の一部としてのルール・ライフサイクルを考えるのは大事だなと思った。
3章では具体的な運用改善のススメ方について解説されている。改善をするべきものはなにかを見える化する方法や、そもそも可視化をどこまで行うべきかの考え方が紹介されていた。このあたりについては感覚で行っていることが多かったが本書で紹介されているCOBIT 成熟度モデルやITIL の継続的サービス改善などを1度読んでみようと思った。ちなみに本書ではCOBIT 成熟モデルの3 → 4 へ向けての改善方法が解説されているらしい。

・COBIT 成熟度モデル

0.プロセス不在
1.個別対応
2.再現性はあるが直感的
3.定められたプロセス
4.管理測定が可能
5.最適化

ITIL の7ステップの改善プロセス

1.改善のためのアプローチ決定
2.測定すべきデータと手法決定
3.データの収集
4.データ処理
5.情報とデータの分析
6.情報の提示と活用
7.改善活動の実践

4章以降は改善のために必要な要素がいくつか紹介されている。
自動化の一部としてCI/CD、IaC、LCDP/RPA について紹介されている。自動化をした方が良いが自動化した際に運用に与える影響について説明されている。IaC の節ではIaC を行った際のメリット・デメリットも紹介されている。ここで紹介されているデメリットについては余り問題視せずにやって良いのではと思っている。作業した人が間違った記載をしていた手順書や、何も説明のない煩雑なサーバなどを運用してきた身としては少しの面倒事は我慢してでもやったほうが後々楽だろうと思っている。
オンプレだけではなくクラウドSaaS での運用についても説明されている。気にするところが変わったり、自分でいじれなくなるところがあったりするがオンプレ→クラウドについてはあまり心配することは無いのではないかと思っている*1
運用を行う上でのセキュリティについても触れられている。守らなければいけないものの選定、セキュリティの意識する箇所などについて説明されている。そして、セキュリティインシデントが起きてしまった際の報告についても説明されている。セキュリティについては以前違う本で入門書を読んだのでもう少し詳しいものを読み進めなければいけないなと思った。

今回気になっていた7章のスキルについては以下の3つのスキルについて説明されていた。

  1. テクニカルスキル
  2. ヒューマンスキル
  3. コンセプチュアルスキル

テクニカルスキルは業務を行う上で必要な知識や熟練度、ヒューマンスキルは人間関係を円滑にするための対人関係能力、コンセプチュアルスキルは複雑な事象を概念化して本質を把握する能力と紹介されている。これらはカッツモデルからの参照となっていた。経営者、マネジメント者、作業者によって必要となる割合は違うがどこの層でもそれぞれのスキルが必要だというのがそうだなと納得した。本書ではそれぞれのスキルの概要が紹介されている。僕にはどれも足りてないから1個1個順番に取得するように頑張らなきゃなと思った。
ちなみにスキル分類表はコチラからダウンロードができるようだ。

8章では運用改善が評価されるためにはということが書かれている。確かに、運用をしている人たちと話をすると評価されていないと思うや大事に思われてないといった意見を言い合うことが多い。このへんは適宜上司と話し合うしか無いのかなと思っている。コストが減りましたなどわかりやすく成果が出るものは評価されるのだろうが、今動いているシステムを止めないためのEOSL 対応や少しづつの自動化などは評価されにくいのだろう。今動いているものを止めることなく動かし続けるというのはすごいことなんだぞといつも思ってはいる。

まとめ

  • 運用改善がうまくすすまないのは運用設計がちゃんとされてないからかなと思った
  • 評価されるようなことを行っていきたい
  • スキルの取得を頑張ろう

*1:クラウドに対する知識の勉強は必須だが

「クラウドネイティブセキュリティ入門」を読んだ

コンテナ技術の活用が本格的になってきたことにより旧来のサーバに対するセキュリティでは足りないことがある。本書では、コンテナ技術、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、宣言型APIに関わるセキュリティ脅威と対策が取り上げられていた。

CHAPTER-01 クラウドネイティブコンピューティングに関連する基礎用語
CHAPTER-02 クラウドネイティブの概要
CHAPTER-03 クラウドネイティブにおけるセキュリティ脅威
CHAPTER-04 クラウドネイティブセキュリティ対策−技術編
CHAPTER-05 クラウドネイティブセキュリティ対策−プロセス編
CHAPTER-06 クラウドネイティブセキュリティ対策−組織編
CHAPTER-07 プラットフォームのセキュリティ対策

前半では本書を読みすすめるためのクラウドネイティブコンピューティングに関連する用語が解説されている。
CHAPTER02 ではコンテナ、マイクロサービス、サービスメッシュ、イミュータブルインフラストラクチャ、宣言型API といったクラウドネイティブ技術の説明と、クラウドコンピューティングに欠かせないプラットフォームとしてKubernetes やOpenShift が紹介されている。

中盤ではクラウドネイティブにおけるセキュリティ脅威の説明がされている。その後は技術として紹介されていた、コンテナ、マイクロサービス、サービスメッシュ、イミュータブルインフラストラクチャ、宣言型API それぞれに関わるセキュリティの説明と対策について解説されている。

後半ではNIST、CIS、OWASP、MITREなどのセキュリティフレームワーククラウドネイティブセキュリティの4Cに沿って整理されている。4C とは以下と説明されている。

  1. Cloud レイヤー
  2. Cluster レイヤー
  3. Container レイヤー
  4. Code レイヤー

また、セキュリティを守るためのフレームワークやプロセスだけではなく、セキュリティ対策と運用プロセスを現行から組織体制・文化を変更していくために見直すべきことや目指すべき組織についてもまとめられていた。

DevSecOps についての解説、DevSecOps を実現するためにSRE が何をするべきかという話も書かれている。SRE がそもそもいないところはどうするのだろうと思ってはいる。

入門書としては薄い本なので読みやすかったし、説明もわかりやすかった。システムを構築するときにセキュリティ対策はなんとなく考えているがちゃんと考えていることはなかったのこれを気に、ちゃんと気にしてみようと思った。

まとめ

  • 薄いし文字も大きかったので読みやすかった
  • クラウドネイティブ技術についてさらっと復習できて良かった
  • セキュリティのことは分かってないので別の本も読んで勉強をしようと思った

202110 振り返り

ワクチン2回目も無事に打ち終わった。
プライベートでは大きな変化がないが、仕事では気がつくと相談をしていた相手や一緒に仕事していた人がどんどん辞めていってしまっているな。自分はまだ辞める気は無いのだが、他のことをしたりしないと転職もできなくなってしまうのではないかと心配になってくることが増えた。
少しでも副業などで違うことにも手を出して勉強していきたいと思っている。実はお話を頂いたのだがキャパが足りずに返事ができていない状態になってしまっている。早めに返事しなきゃ。

本を何冊か読んだのだがFIRE するかお金をたくさん儲けれるお仕事がしたい。

べんきょうかい

データに関する勉強会に出ることが相変わらず多い。
その他にもスクラムの勉強会にはいまだに参加をしている。そろそろなにかしら実践できることはないものかと思ってはいる。

ほん

コミックがやっぱり大半を超えているが本を読む時間が増えた気がする。
組織ってどうやったらうまくいくのかわからないことばかりなのでなにかわかるようになることがないかなと読むことが増えた。
来月からはもうすこし技術的な本を読む時間を増やしたいと思っている。あとは、お金欲しい。

えいが

ワクチンも打ち終わったし久しぶりに。
ずっと見ているし好きだから 007 は映画館に観に行きたかったので行ってしまった。

ぶろぐ

本を読んだので。
あいも変わらずチームとか組織とか、インフラとかに興味が強いかな。

hihihiroro.hatenablog.com

hihihiroro.medium.com

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

「キャパシティプランニング」を読んだ

薄いし気になる内容だったので積んである本棚から抜き出して読んでみた。
購入履歴を見ると2017年に買っていたらしい。

第1章 キャパシティプランニングにおける目標、課題、およびプロセス
第2章 キャパシティの目標設定
第3章 計測:キャパシティの単位
第4章 動向の計測
第5章 配置
付録A 仮想化とクラウドコンピューティング
付録B 瞬間的な増加への対応
付録C キャパシティツール

Flickr のキャパシティプランニングを実例を混ぜながら紹介してくれていた。
本書で紹介されているキャパシティとはWeb サービスの運営に必要なリソース(サーバ、ディスク、ネットワーク回線、データセンタなど) を指している。これらのリソースが足りない状態にならず、ただ潤沢に余りすぎている状態にもならない状態をいかにうまく見積もり、準備するために何をするべきかが紹介されている。

見積もり予測をするためには計測が必要だということがところどころに書かれている。「推測するな計測せよ」という言葉を聞くことが多々ある。本書でもまずは計測をすることをすすめている。そして、実際にFlickr で計測するために行ったこと、行った結果のグラフなどが紹介されているのである。実際にサービスの計測データが載せられて解説されているので想像がとてもしやすかった。
本書では計測はオプションではなく必須のものであり、エンジニアリングのためだけではなく財務、サービス、製品管理など幅広く情報を与えれると説明している。これらの計測のため条件を変えて実験することなどが丁寧に書かれていた。3章と4章で計測、そして計測を使っての予測の説明がされているので自分のサービスでも同じくやってみようと思った。

付録ではクラウドの利用について、実際にクラウドを使用しているサービス、仕様を諦めたサービスの選定理由も含めて紹介されている。クラウドサービスによって得られるものと得られないものを利用者が把握し、利点が自社のサービスや成長の度合いに合致する際には利用することが書かれている。当たり前のことだが大事なことだろう。クラウドを使っていると金の弾丸に頼ってしまうことが多いし、それで良いとも思っているがちゃんと調べることも大切だろうな。

まとめ

  • 繰り返し読むことでテクニックを身に着けたい
  • 計測とフィードバックをする仕組みをつくろ
  • インフラが利用可能であることを信頼せよ。しかし、自分で確認せよ。

「心理的安全性のつくりかた」を読んだ

チームでうまく働くためには心理的安全性が大事だとよく聞くので、心理的安全性の作り方を学んでみようと思った。

心理的安全性」とは、組織やチーム全体の成果に向けた、率直な意見、素朴な質問、違和感の指摘がいつでも誰でも気兼ねなく言える状態のことと説明されている。ヌルい職場と心理的安全性の高い職場は別であると紹介されている。安全という言葉を日常的な意味で捉えると間違ったチームになってしまう。
本書ではチームの心理的安全性の因子を日本にあわせて4つにまとめられている。

  1. 話しやすさ(何を言っても大丈夫)
  2. 助け合い(困った時はお互い様)
  3. 挑戦(とりあえずやってみよう)
  4. 新奇歓迎(異能、どんとこい)

もともとは、「無知・無能・邪魔・ネガティブ」とネガティブな因子を紹介されていたが、日本版ではポジティブな因子が紹介されている。これらを守るだけで心理的安全性のあるチームになるわけではないんだろうが、心理的安全性のあるチームにはかならずある因子なのだろう。

心理的安全なチームを作るためには、心理的柔軟性のある行動が大事。心理的柔軟性を身につけるための3つの要素が紹介されている。

  1. 必要な困難に直面し、変えられないものを受け入れる
  2. 大切なことへ向かい、変えられるものに取り組む
  3. それら変えられないものと、変えられるものをマインドフルに見分ける

思考を優先させるのではなく、現実のフィードバックを優先することが大事と説明されている。その他にも変えられるものから変えることの大事さが説明されている。人が変わることを期待するだけではなく、自分が変わることが大事。自分が積極的に変わることによって自分の行動の影響で他人を、他人の価値観を変えていくことをしていくことができると紹介されていた。この章を読んだときに思い出したのは、椎葉さんが Scrum Fest Osaka 2021 で話していた内容そのままだなと思った。椎葉さんにはイベントのあと再演してもらったが頷くことしかできなかった。

speakerdeck.com

実際に行動を変える手法として行動分析が紹介されている。自分を変えなければいけないと思っているので一番気になったのはこの章だった。
行動分析の、基本的なフレームワークが紹介されていた。

・ きっかけ→行動→みかえり→行動
「きっかけ」によって「行動」が起き、行動のあとの「みかえり」が、「行動」に影響を与える。

行動を制御するみかえりとして2つのみかえりが定義されている。
良いみかえりは行動が増え(好子)、悪いみかえりは行動が減る(嫌子)。みかえりが行動に影響を与えるということは、良い行動を行うためには好子を増やすことが大事なのだろう。嫌子が増えると罰を恐れて心理的「非」安全性なチームができあがってしまう。何が好子・嫌子なのかを考えて、できる限り好子を返すことを考えていきたい。

相手の行動を変えるためには自分が変わっていくしか無いと思う。まずは自分が変わっていくしか無いなと思った。感謝をすぐに伝えるや、否定的な言葉を言わないや、具体化した話をするなどできることから始めてみようと思った。

まとめ

  • まずは感謝を伝えるところから
  • 良い行動のためには良いみかえりをする
  • 心理的安全性を阻害している要素をさがしてみよう*1

*1:自分だったらどうしよう・・・

「Amazon Web Services企業導入ガイドブック」を読んだ

転職を考え始めた頃にクラウドのこと知っておかなきゃなと思って買っていた本。
一気読みをした。

#1 [概要編] クラウドコンピューティングAWS
#2 [概要編] AWS のさまざまな利用シーン
#3 [概要編] AWS のサービス
#4 [概要編] AWS のセキュリティ概要
#5 [戦略・分析編] クラウド導入のプロセス
#6 [戦略・分析編] 現状分析の進め方
#7 [戦略・分析編] クラウド標準化
#8 [戦略・分析編] PoC による事前検証
#9 [概要編] クラウドにおけるTCOと費用見積もり
#10 [設計・移行編] クラウド利用時の開発プロセス
#11 [設計・移行編] クラウドにおけるシステム設計
#12 [設計・移行編] クラウドにおけるサイジングと性能測定
#13 [設計・移行編] クラウドへのシステム移行とデータ移行
#14 [運用・改善編] AWS における運用監視
#15 [運用・改善編] クラウド活用の最適化

AWS とはというよりも、システムをクラウド移行する、作成するとなったときに何を考える必要があるかが説明されている。
クラウド移行することによるメリット、難しくなることや運用者に求められることなどが丁寧に書かれていたなと思った。クラウド移行を考えるとなったときに問題扱いされることは出版時期よりは減ってきているのかなと思うが、今でも同じことを考える必要はあるのだろうなと思った。

また最後の章ではクラウドを上手に活用するための7つの設計指針を久しぶりに読んだ。

  1. Design for Failure (障害に備えた設計)
  2. Loosely coupling sets you free (粗結合かつ凝集度の高いシステム設計)
  3. Imprement Elasticity (伸縮自在性を取り入れる)
  4. Build Security in every layer (セキュリティを各レイヤーで構築する)
  5. Don't fear constraints (成約を受け入れて、うまく利用する)
  6. Think Parallel (並列度をあげるように設計構築)
  7. Leverage different storage options (様々なデータストアのオプションを活用する)

今の自分が運用しているシステムも見直しをすることで色々、変更するべき箇所などありそうだから考えてみようと思った。

まとめ

  • クラウド活用ちゃんとできているんだっけかを見直してみようと思った