Outputしないと参加出来ない枠 - 無料 17/30
アウトプットする人だけが参加出来る回です
- ssmjpはアウトプットしない人は知的な便秘というキーワードが時折出てきますが、そういえば参加者のアウトプットとは一体何だろうと思ったところから今回の開催内容となりました。
JAWS-UGコミュニティ運用とSSMJPとの比較あれこれ
jaws について
- jaws-ug （AWS Users Group – Japan） とは
- jaws-ug 全国 50+ 支部
- jaws なのに海外支部がある
- jaws 五反田 1800 人きました。
- slack make-jawsug #general でいろいろ告知している
- security-jaws aws+security をコンセプトに立ちあげました。
- X-tech jaws FinTech に限らず InsureTech HealthTech MediTech AdTech EdTech などを総称して、クロステック xTech とうがそれとは違う。クロステックは業界をまたぐが、X-Tech は業界をまたぐものの aws がどこかでからむ。ascii に記事がのってるよ。
コミュニティの運営について
- ドタキャン率を減らすのが、コミュニティを運営するにあたって悩みの種である。X-Tech JAWS は、登壇者を見つけることが悩みではある。なんか Web でサービスを見つけて、逆引きして route53 を使っていればオファーかけるということを繰り返している。
| コミュニティ | ドタキャン率 |
|---|---|
| Security JAWS | 30% |
| X-Tech JAWS | 40% |
| ssmjp | 20%-30% |
- JAWS-UG運営 行動規範 - Code of Conduct - ってのがあり、大変参考になります。
コミュニティを運営していてよかったこと
- 登壇者調整で先の情勢を知ろうとするモチベーションとなる、近いうち、コレ来そうだから、次回これやろーとか
- グループマネジメント力の向上
- コミュニティ運営者同士の会話から give&take の連鎖
- give は output の連鎖にもつながる
- （副作用?）知らない社内の人が自分をしっているが、俺はお前を知らない
devrel 活動、社内で技術をやっているやつらはいるんだけど、外向けのアウトプットが下手くそだなと思うことが多いのでこれうまいと思います。
- DevRel活動とは? [エンプラでDevRelコミュニティをゼロから作ってみた] (https://www.slideshare.net/ohashimamoru/devrel-119371496)
- ここでは「技術者同士の繋がりを作る活動」と定義します https://devrel.jp/ DEVREL とは Developer Relations の略、外部の開発者とのつながりを形成し自社製品/サービスを知ってもらうためのマーケティング活動
波田野さんからのコメント
- 自分にとってやりやすい人数以上を集めてしまうと疲れてしまって、流行っているコミュニティでも運営ができなくなります。
SphinxCon JP 2018のご紹介
うさたーんさん
sphinx でどんなもんなのかは sphinx で作られた Webサイトをみるとよいでしょう。
- SphinxCon 2018 2018/11/28（2018/11/16 抽選） あります → その場で登録しました
- もともとドイツ人が作ったんだけど、今は日本人がメンテナーです。日本語で質問できます。
デモありました。普段つかっているのであんまり見てなかった。
最近わたし発見したけど こんな図も埋め込めます。 Python3 じゃないとだめですけど、便利便利。
「正しい」運用手順を作る
- jaws-ug cli 別名: 転職専門支部、手順書レビュー支部
みんな大好き「運用自動化」みんな大苦手「運用手順書」
- 「運用手順書」が苦手なのに「運用自動化」を得意といえるのか
- 「運用自動化」は「運用標準化」の一つ （去年発表しています）。
- まともに自動化を実装できるひとがいない（炎上するので公にはいってませんが、裏の意味です）
- 運用の定型化を飛び越えて運用自動化を行うと、より仕様のバグが起きやすい
- 「運用手順書友の会」盛り上がれば盛り上がるほど暗くなる会
正しい運用手順書とは
- レベル 1 論理的に正しい 論理的
- レベル 2 実質的に正しい 合目的的
- レベル 3 読み手に取って正しい 伝承的（利便的にするべきか悩んでいる）
レベル 1. 「論理的に正しい」手順書
- その通りに実施していれば論理上の正しい結果になるはずである（おかしい点がなければ OK）
まずは、論的な手順書をかけることが第一歩 - 「論理的に正しくない」手順書とは
- 複雑な分岐や不適切な共通化が事故を生む、とりあえずやってみるけど途中でわからなくなる。共通手順とちぐはぐになってしまうとか。
- 日本の IT は論理的ではない
- 論理的に正しい手法やツール
- 三段論法 （大前提と小前提から結論を導出）
- 演繹的推論 （理論や知識から導出）
- 集合論 （論理演算、術後論理、照明など）
- バリデータは論理的な正しさ（形式的な正しさ）をチェックしてくれる（手順の最初のとっかかりといえる）。
レベル 2 「実質的に正しい」手順書
- 手順通りにやれば、本来の目的を果たせる手順書。
- 矛盾のない手順書をかけるようになること。
- 「実質的に正しくない」手順書とは
- 手順書通りにやっても、目的を果たせない手順書。手順書の確認手順が確認になってない。
- すなわち目的があいまいなためである。
- そもそもレベル 1 でいう論理的になっていないとか、adhoc で書いていると致命傷になる。
- 意味的に正しい手法やツール
- 形式手法（ソフトウェア工学における意味論的手法）
形式手順は主に組み込み系で使われているが、正直ハードルが高い - ボーア理論（プログラムの正当性を推論）
ボーア理論は手順書への部分的適用が可能。
問題はレベル3 「読み手に取って正しい」手順書
- 読み手に取って正しい手順書とは?
- 読み手が手順書を正確に理解し、記述の真意を容易に把握することができる手順書。
- 引き継ぎも容易になり、さらに現場への手順書の保守を移管しやすい。
- 伝承的な手順書をかけるようレベルアップ
- 読み手に取って正しくない手順書とは?
- 読み手が理解できない手順書
- 「わかる人にはわかる手順書」はひき継げない。
まとめ
- レベル2 までは訓練しだいで習得可能。
- レベル3 、論点整理中
おまけ
- 「運用手順書」が苦手 ← → 「運用自動化」が得意
とはいえ、両方とも論理的に正しいことを重視することが必要である。 - 「論理的に正しいこと」を重視しないしない人は「運用手順書」をかけない
- そのまま実装しようとして「運用自動化」の結果破綻 → よくあるのではないでしょうか
- 「運用手順書」にいったん落とすことによって、ノイズ除去。「運用手順書」を作りにあたり、このコード 100% 無駄だってねというのもある話。
- 運用自動化で失われがちな時系列（ストーリー）を残すという大きな役割が運用手順書にはある。
- 成功した自動化
- 手順書に沿って作成したもの
- 失敗した自動化
- adhoc に作ったもの。
- 夢を追いかけたもの
- ansible はおのずとレベル 2 までを実現できる、動くところまでいけば（しかし、時系列がなくなっちゃうのでレベル 3 はむしろ遠ざかる）。
- ansible もいいけど、ansible + 手順書が必要じゃないですか?