新年初自転車。1/8 板室温泉の近くまで登って雪景色を眺めてきた
走行距離 48km 獲得標高 312m のお散歩ライド
続きを読むSemantic Software Design - Chapter 2. The Production of Concepts
2章の途中まで流し読み。抽象度の高い話が続いていて、咀嚼できない。実践的な話だけ拾い集めて読む。3章に入ると「脱構築」や「デリダ」とか出てくるぽくて、そこまで風呂敷広げるんかい〜 。そういうこともあって、Google 翻訳 / DeepL 翻訳で読んでるとちょいと辛い感じがある
Part of the work of the new architect-creative is to help create those requirements, both functional and nonfunctional. To see what needs to be done, what might work, what structure accounts for what we think we want the system to do, or what we think someone else we’ve never met might want or need the system to do three years from now when it’s harder to change and how to accommodate that.
新しいアーキテクト＝クリエイティブの仕事の一部は、機能的なものも非機能的なものも含めて、そうした要求の作成を支援することである。何が必要で、何が機能し、どのような構造で、私たちがシステムに何をさせたいと考えているか、あるいは私たちが会ったことのない誰かが3年後にシステムを変更することが難しくなったときに何をしたいか、何を必要とするかを説明し、それにどう対応するかを確認することです。
This book has a single primary purpose among many purposes: to help you better design software. To do so, it advances a new model, a new approach, a new set of ideas and tools called semantic software design.
本書は、多くの目的の中で、たった一つの主要な目的、すなわち、より良いソフトウェア設計を支援することを目的としています。そのために、セマンティックソフトウェアデザインと呼ばれる新しいモデル、新しいアプローチ、新しいアイデアとツールのセットを進めています。
抽象度の高い話が続いていて迷子になりそうなところで、なんのための本なんだっけ? を改めて再確認する
The problem with software—a chief reason our projects fail—is a failure of our language. We are not architects. Not even close. We do not build buildings with an obvious and known prior purpose, which is an approximate copy of the same kind of building people have been making and using for thousands of years, using tangible commodity materials on a factory line. Quite the opposite.
ソフトウェアの問題点、つまりプロジェクトが失敗する最大の理由は、言葉の問題です。私たちはアーキテクトではありません。それどころではありません。私たちは、何千年も前から人々が作って使ってきたのと同じような建物を、目に見える商品材料を使って、工場のラインでほぼコピーしたような、明白で既知の事前目的の建物を作ることはしません。全く逆だ。
あんちぽさんか、しばたさんが、ソフトウェアってコード書き出すまでは頭の中にあるもんだから みたいな話をずっと前にしてたの思い出す。
Accomplish, Avoid, Fix
To be useful in a typical software project, your concept will generally be about one of three things: accomplishing something, avoiding something, or fixing something:
一般的なソフトウェアプロジェクトで役に立つには、一般的に「何かを達成する」「何かを回避する」「何かを修正する」という3つのうちのどれかをコンセプトとすることになります。
...
顧客が達成したいこと、避けたいこと、修正したいことを考える。文章で、この質問に答えてください。 誰が、いつまでに、どのような理由で、何を望んでいるのか？
Divergent and convergent thinking
As you work through your concept, you should go through two stages, divergent thinking, followed by convergent thinking.
コンセプトを練る際には、発散的思考と収束的思考の2段階を経る必要があります。
なんでもかんでもあげてみる考え方から、コンセプトに絞り込んでいく考え方の話。
convergent thinking は以下の通り続く
1. What absolute constraints are known? 2. How might these candidates fit within a budget, if known? 3. How might these candidates fit within a timeline? 4. What known elements of the business or technology strategy do these candidates support? 5. What new opportunities does this create? 6. What positive and negative elements of our current landscape of People, Process, and Technology does this enhance or aggravate? 7. What people or roles would need to approve or work together with these candidates?
エレベーターピッチ的なフレームワーク紹介への導入の文章
ここで 著者の Concept Canvas が図示で紹介される
1. Concept statement 2. Statement of need 3. Alignment with strategy 4. Idea components 5. Path forward
ここまで読んで終わり。
Semantic Software Design - Chapter 1. Origins of Software Architecture
1章を流し読み。目に留まった箇所の引用を掲載する。引用の翻訳は DeepL による。
This is a way of saying that software didn’t even know it existed as its own field, separate from hardware, a mere 50 years ago. Very smart, accomplished professionals in the field were not sure whether software was even a “thing,” something that had any independent value.
これは、ほんの50年前までは、ソフトウェアがハードウェアとは別の独立した分野として存在することさえ知らなかったということを意味している。その分野の非常に賢い、熟練した専門家たちは、ソフトウェアが「もの」であり、独立した価値を持つものであるかどうかさえ分からなかったのです。
ソフトウェア/ハードウェアが別物として当然だと思っていたので、古典の話は興味深い。
The term “architect” as used in software was not popularized until the early 1990s. Perhaps the first suggestion that there would be anything for software practitioners to learn from architects came in that NATO Software Engineering conference in Germany in 1968, from Peter Naur:
ソフトウェアで使われる「アーキテクト」という言葉が一般化したのは、1990年代初頭のことです。おそらく、ソフトウェアの実務家がアーキテクトから学ぶべきことがあるという最初の提案は、1968年にドイツで開催されたNATOソフトウェアエンジニアリング会議において、Peter Naur氏からなされたものでしょう。
提案自体はずいぶんと古いものらしい (ただし、続く本文で The problem with Naur’s statement is obvious: it’s simply false. It’s also unsupported. として、声明自体が間違っていると主張されている)
Dividing roles into distinct responsibilities within a process is one useful and very popular way to approach production in business. Such division makes the value of each moment in the process, each contribution to the whole, more direct and clear. This fashioning of the work, the “division of labor,” has the additional value of making each step observable and measurable.
ビジネスにおける生産活動のアプローチとして、工程内での役割を明確に分けることは有効であり、非常によく知られている方法の一つです。 このような分割により、プロセスの各瞬間の価値、全体への各貢献がより直接的かつ明確になる。このような仕事の組み立て、すなわち「分業」には、各ステップを観察し、測定できるようにするという付加価値もある。
GitHub Actions で一個のステップ実行時間が長くデバッグが大変だったのを、分割して解決しようとした ... というのを思い出したりした。その他、日々の開発でも意識せずにやってることもあるだろう
付録
https://learning.oreilly.com/library/view/semantic-software-design/9781492045946/ch01.html
インシデントマネージメントについての覚書エントリ - Modern System Administration By Jennifer Davis
12 Managing Incidents の章で オンコール対応とインシデント管理についてページが割かれていた
12. Managing Incidents
インシデント管理の目的を The aim of incident management is to minimize the damage, costs, and recovery time. と唱えてから
- インシデントの定義は組織によって異なる
- Blameless な組織文化
- 役割と責任の分担
- コミュニケーションの確立
- インシデント後のふりかえり ( postmortem, after action review ... )
... あたりをさらっと触れている内容だ。よく見かける感じのサブテーマ・構成で書かれている。SRE 本や PagerDuty のドキュメントあたりを読んだことがある人なら、目新しい記述はさほど多くはないだろう。
可観測性とか IaC とか デファクトになった感のあるテーマも抑えてあって、「なるほど これがモダンか」と、さらっと読み流すのによいボリュームの書籍
toruby 175th に参加しました - セコンさん おいで那須
juen29 さんと連れ立って、セコンさん ( @hotchpotch ) さんが初参加の回でした。おいで 🍆 〜
私はチャリで駆けつけました。CDK。
チャリできた #toruby pic.twitter.com/khy4YKjgZG
— ito hiroya (@hiboma) 2021年11月10日
勉強会の内容
Python の言語仕様の話 (Ruby と比較して言語のパラダイムを比較する ) から、型ヒントの話、機械学習の話までだーっとお話を聞かせてもらう回だった。内容がすごい密度なんだけど、用語や論旨が的確でわかりやすいの、さすがセコンさん節って感じで、懐かしい気分にもひたれた。
聞いてるみなさんからも「△△はどうなの?」「〇〇だと思ってた〜」と質問も多くていい雰囲気だった。
ご飯
会が終わった後に、よねざわさん, セコンさん、june29さんと フライングガーデンで肉
↓ に載ってる系列店。
いまいまは 会食もできる状況なので、よかったよかった。
この辺だと自転車のお店はどこなんだ? とか、みんな どこで知り合いになったのだ? とか、観光にくる人の那須塩原と住んでる人の那須塩原のイメージの食い違いだとか ... そんな話をした。
CloudNative Days Tokyo 2021 「インシデントレスポンスを自動化で支援する - Slack Bot で人機一体なセキュリティ対策を実現する」の発表を終えた - アーカイブ動画の宣伝とふりかえり
技術のエントリです
2021年11月4,5 日の日程で CloudNative Days Tokyo 2021 がオンライン開催されました。
私は GMOペパボの事例をひっさげて インシデントレスポンスを自動化で支援する - Slack Bot で人機一体なセキュリティ対策を実現する というタイトルでの発表でした。このエントリで、資料をまとめておきます。
アーカイブ動画
こちらで公開されています
スライド
PDF もダウンロードできます。
スライド内で引用している書籍やブログのリンクを開きたい場合は、PDF でご覧になるとよいでしょう
感想
twitter やはてなブックマークでも いろいろなコメントをいただいており、発表して確かに手応えがあった感じです
そもそもの話として、障害やセキュリティインシデントは未然に防ぐの好ましく、何も起きないようにする、あるいは、何かがおきてもシステムに問題がないよう信頼性を高めていくのが大前提でしょう。
しかしながら、現実にはちょっとした綻びでもって可用性・信頼性・完全性が失われてしまい 「インシデント」を引き起こします。平時とは違う緊急のプレッシャーに晒されて対応する人々を支援・組織化するインシデントマネジメント ( 組織の力 + エンジニアリングでの支援 ) を整えておくことで、高いレジリエンスを獲得できるでしょう。
障害対応やセキュリティインシデント(の疑いがある事象) についての対応などは 公開するのが難しいところもあるでしょうが、知見や取り組みをオープンにディスカッションできればと思っています。
謝辞
CNDT 運営のみなさま ありがとうございました!