アンチフラジャイルの世界
kawasima
NoOps Meetup Tokyo #8

「わからない」にはレベルがある
今日覚えて帰ること①

Cynefin Framework
Chaotic
Complex Complicated
Simple / Obvious
Disorder
問題に対する解: 1つは既知
(最良かどうかは分からない)
問題と解の因果関係: あり
問題の解き方: 把握-分析-対処
問題に対する解: 1つで既知
問題と解の因果関係: あり
問題の解き方: 把握-分類-対処
問題に対する解: 未知
問題と解の因果関係: あり
問題の解き方: 調査-把握-対処
問題に対する解: 未知
(問題も不明)
問題と解の因果関係: なし
問題の解き方: アクション-把
握-対処
解決策を得るための方向にはパ
ターンがある
既知の解法から選択して適用す
る (Good Practice)
既知の解法を適用する (Best
Practice)行動を起こして、Complexな状
態に移行させる。
分からないことが分からない
分からないことがない
分からないことが分かっている
何もわからない
http://www.mext.go.jp/b_menu/shingi/gijyutu/gijyutu7/011/siryo/__icsFiles/afieldfile/2014/12/16/1353933_4.pdf

今日覚えて帰ること②
「複雑」には2種類ある
分からないことが分かっている
分からないことが分からない

「複雑」と「複雑系」は違う
Complex Chaotic
今日覚えて帰ること③

どのレベルにあるのかによって
取るべき戦術が異なる

Simple / Obvious
手順書のある安定したシステムの運用作業
状況を把握し、既知のベストプラクティスを適用する

Complicated
状況を把握し、複数のソリューションから
最善なものを適用する
デザインパターンやフレームワークを使った開発

Complex
状況を調査し、進むべき道を決め、軌道修正しながら進む
ターゲットが時間と共に動くサービス開発

Chaoticな状況の生存戦略

Fragileの対義語が無いので造られた
Fragile
Antifragile
Robust
取り扱い注意
どうぞ落っことして
みてください
取り扱いに注意するな
という意味ではない

Antifragileが載っている書籍

世の中の出来事の非対称性七面鳥のおじさんへの信頼度
t
毎日エサを与えられ、
信頼度は日々蓄積されていく
が…

予測が出来ない大きな変動
(Black Swan)
リーマンショックや日本のバブル崩壊、3.11
後になってみれば予測可能だった気がする(後知恵バイアス)
実際、予測は役には立たない。
ありそうもないことを
人は過小評価しがち

Black Swanへの態度
Black Swanが起きたとき、反省すべきは…
事象そのものを
予測できなかったこと
FragileやAntifragileを
理解していなかったこと
予測ミスによる損失を最小化し、利得を最大化する方法を考えよう

Benefit
Change
Cost
Antifragile
Resilient
Robust
Fragile
https://developers.redhat.com/blog/2016/07/20/from-fragile-to-antifragile-software/

Cynefinフレームワークとの対応
Fragile
Robust
Resilient
Antifragile
変動は想定せず(しなくてもよ
く)、ベストプラクティスを
粛々と実行する。
変動を予測し、それに耐えうる
ように最適なソリューションを
適用する。
変動を予測し、それにシステム
が適応できるように設計する。
変動は予測せず、発生したとき
の対処(あわよくば大きなゲイ
ンを得る方法)を検討する。
Chaotic
Complex Complicated
Simple / Obvious

Simple/ObviousがChaoticに変わるケース
ユーザが急増したときに、どういうBlack Swanが起こる
(ユーザは正規のユーザだけとは限らない)
ユーザは、ひどいもんだ。
ユーザがいなければ、システムはもっとうまく動くのに。
『Release It!』4章 安定性のアンチパターンより
あなたのシステムが安定運用できているのは、
少ない行儀の良いユーザのおかげかもしれない…

ソフトウェアの世界への適用

Tinkering
AdobeのKickboxやGoogleの20%ルール
https://news.mynavi.jp/article/20151019-am201506/

Fault Injection
(in Production)
1.定常状態における振る舞いの仮説を立てる
2.実世界の事象は多様である
3.本番環境で検証を実行する
4.継続的に実行する検証の自動化
5.影響範囲を局所化する
Chaos Engineeringの5原則
https://principlesofchaos.org/?lang=JAcontent

自動バグフィクス
https://www.comp.nus.edu.sg/~abhik/pdf/cacm19.pdf

例) DeepFix
http://www.iisc-seal.net/deepfix
Deep Learningを利用した、パッチの自動生成

Auto Tuning
https://qiita.com/kawasima/items/5d8a8a9b84aae6d7de71

Property Based Testing
Example Based Testing
●
入力: 具体的な値
●
Assertion: 決まりがない
(…ので、マッチポンプテストに陥りがち)
Property Based Testing
●
入力: スペックにしたがい自動生成
●
Assertion: 期待したふるまいか?を検証

例) Web APIのProperty Based Testing
https://qiita.com/kawasima/items/25836e443e8822e89b24
Clojure specのJavaScript移植

例) Web APIのProperty Based Testing
定義したSpecに沿って、パラメータを生成しAPIを自動で叩く。
Spec外の値も生成できると、Antifragileに近づく
(まだこれから)

Noise除去
データに触れれば触れるほど、「信号」と呼ばれる貴重な情報よりも、
ノイズに触れる可能性は不釣り合いに高まっていく。
https://medium.com/netflix-techblog/scryer-netflixs-predictive-auto-scaling-engine-part-2-bb9c4f9b9385
「静観」をシステムが判断したい…

Antifragile System
を支える技術

Microservices
Antifragileのためとしては、以下2点
障害の局所化 Tinkeringの環境

亀裂の伝播を防ぐ
1.タイムアウト
2.サーキットブレイカー
3.隔壁
・・・
必要なすべては、
Release It!の中に

DevOps
Culture
Automation
Measurement
Sharing
重なりは多い
DevOps Antifragile
失敗を前提とした案件

Road to DevOps &
Antifragile
① DevとOpsを分離する
② Opsを無人化する
③ OpsのAntifragile化

DevとOpsの分離
ITILやSOX法への対応のためには、開発者が
本番環境に気軽にアクセスできることはまかりならない
開発環境 本番環境
運用チーム開発チーム
アクセスは互いに
制限される

Opsの無人化
Devが本番環境にログインしない
開発環境 本番環境
運用チーム開発チーム
デプロイ対象の提供
本番のメトリクス
発生障害情報の連携

OpsのAntifragile化
開発環境 本番環境
運用チーム開発チーム
Tinkering / FIT
本番環境にストレスを加えて強くする

Wrap up

置かれた状況がどこかを知ることが最重要
仮説検証
Simple / Obvious
ComplectComplex
Chaotic
Tinkering
Fault Injection
専門家のアサイン
ルール作り / 訓練
Agile パターンランゲージ
グッドプラクティスが分かっていることや事前調査
もできないことを仮説検証しないために…
今日覚えて帰ること④

複雑さの推移
何があたるかサッパリ
Complicated
Chaotic
Chaotic
Complicated
Simple / Obvious
勝ち方を見つける
Complex
事業の安定収益化
Business Side
System Side
t

λove chaos