NoOps Meetup Tokyo #3 カンファレンスノート #NoOpsJP

# イベント情報
> *NoOps = No "Uncomfortable" Ops*
> NoOps Japanでは 「システム運用保守の"嬉しくないこと"をなくそう！」 をテーマに、 NoOpsを実現するための技術・設計手法・開発運用保守サイクル・ツールや考え方・事例などを共有していきたいと考えています。
> NoOps Meetup Tokyo では業界の第一人者のみなさんに登壇いただき、それぞれの視点でのNoOpsをお話いただきます。 また今回は、NoOps Meetup and OpenHack 企画ネタ応募LTを募集します。今後のNoOps Japanの活動で取り上げてほしいテーマをぜひアピールください！

[NoOps Meetup Tokyo #3 - connpass](https://noops.connpass.com/event/109683/)

過去のカンファレンスノートはこちら
[NoOps Meetup Tokyo #1 カンファレンスノート - Qiita](https://qiita.com/saitotak/items/2f85918aa329c4af2073)
[NoOps Meetup Tokyo #2 カンファレンスノート - Qiita](https://qiita.com/saitotak/items/0015d1c8a845c86274a1)

# 資料リンク集
- Main
    -  [NoOps Meetup Tokyo #3 Opening](https://www.slideshare.net/hiromasaoka/noops-meetup-tokyo-3-opening)
    -  [Serverless の自動回復と自動化のためのアーキテクチャ](https://www.slideshare.net/TsuyoshiUshio/serverless-125267752)
-  LT
    -  [NoOpsは悪い文明!!粉砕する!! - Speaker Deck](https://speakerdeck.com/changeworld/noopshae-iwen-ming-fen-sui-suru)
    -  [一人から始める hackfest! ～ OpenHackへの最初の一歩](https://www.slideshare.net/dzeyelid/challenge-openhack-for-your-noops)
    -  [DevOpsとちょっと外側とNoOps - Speaker Deck](https://speakerdeck.com/amemolee/devopstotiyotutowai-ce-tonoops)


# 光り輝くTBD（仮） / 西谷 圭介 `@Keisuke69` Amazon Web Service Japan
- 2 pizza team / you build, you run
- AmazonにSREはいない / NoOps
    - 以下、すべてのメンバーは2pizzaなサービスチームの中にいる
        - SDEは開発に日々集中
        - PMはディレクション
        - TPMは開発をドライブすることの手助け
        - SEはインフラ／ツール整備
        - SDETは組織全体でテストを良くする
- チームには権限が与えられ、多くの自由が認められている
    - 大体スクラム、カンバンでやっている、言語も自由、採用もチームごとに実施
    - それらにはチームとして高い水準を維持する必要がある
- 高い水準を維持するには
    - オンボーディング、トレーニングを通じて
    - あらゆるスケールで定義されたパターン／プラクティスと20年以上の組織的ナレッジ
    - Our Leadership Principles
- Our Leadership Principles とは
    - 全てのAmazonianが心がける14の信条・行動規範、面接のカルチャーフィットを図る指標としても使われる
        - 参考:[求める人物像｜Amazonでは、全員がリーダー](https://www.amazon.co.jp/b?ie=UTF8&node=4967768051)
- Think Big:顧客価値提供のため新たな視点を持つ
- Bias for action:スピード,やり直しの聴くことも多い,fail fast
- Hire and develop the best:カルチャーフィット、メンタリング、peerフィードバック
- Have Backbone; Disagree and commit:誠意を持って異議を唱える、安易に妥協しない、決定には全面的コミット
- Insist on the Highest Standard:常に高い水準を目指す、コードレビュー
- Deliver Result: 結果が大事
    - イテレーションを小さな単位で繰り返して回す
        - MVP:顧客のフィードバックを早く得る
- 運用ゼロは幻想
    - NoOpsは難しくてもLessOpsはできる

# Serverless の自動化と自動回復のためのアーキテクチャ / 牛尾 剛 `@sandayuu`
- サーバレスのアーキテクチャ
- 自動化のためのアーキテクチャ
- 自動回復のためのアーキテクチャ
- ゴール:NoOpsに取り組むための最初の一歩を始めてほしい
- サーバレスのアーキテクチャ
    - Event -> Trigger -> Input Bindings -> [CODE] -> Output Bindings
        - みんなテスト書かない
- Azure Functions のユニットテスト
    - Unit Test -> Integration Testing -> E2E
- Unit Testの重要性
    - これなしではCICDは意味がない
    - 実装に自身をもつ
    - テストがないコードは存在しないのも同じ
    - 良いアーキテクチャを導く
- 良いテストとは
    - リグレッションエラーを検出できる
    - False Positiveの割合が少ない
    - 素早いフィードバック
    - メンテナンスコストが低い
- Hexagonal Architecture
    - ドメインロジックは切り出し、外部境界にモックを割り当ててInput-OutputをAssertする
        - Domain Object分割
        - コラボレーターとの接点をMockする
        - Bindingsを使う
        - 単一責務の法則
        - インターフェース導入
        - Wrappter
        - リポジトリパターン
- Markdown翻訳のデモ
    - [TsuyoshiUshio/MdTranslator: Translate markdown document on your repository.](https://github.com/TsuyoshiUshio/MdTranslator)
- サーバレス関数設計の要
    - 単一責務の法則（Single Responcibility）
    - 冪等性
    - リトライ単位での関数
- 分散トレーシング
    - 分散されたマイクロサービスを統一的に見る
    - HTTP Correlation Protocol
    - W3c Trace Context
- NoOpsに向けて一歩を踏み出そう（UnitTestから！）