AmplifyでNuxt.jsのhello worldを表示させる

先日初めてAWS Amplifyを触りました。いろいろよしなにやってくれるサービスですが、なにをどうすればいいのか理解しづら部分もあったので、できるだけわかりやすくhello worldを表示させるまでの過程を記述します。

結局なにをするサービスなのか？

かなりざっくりですが、フロントからバックまでよしなに構築してくれるフレームワークだと思っています。
フロントエンドに関しては、reactやvueなどで記述されたフロントエンドリソースをテストからデプロイまでしてくれます。バックエンドに関しては、Amplifyが提供してくれている機能（認証、データベース、APIなど）であれば、Amplify CLIというコマンドラインによって対話形式で簡単に利用することができます。
こういったサービスがなかったら、AWSリソースを自身で構築して繋ぎ込みをしなければ行けませんでした。そこを簡単に行えるようにしてくれるサービスぐらいに捉えておけばいいかなと思います。

Nuxt.jsでhello world

フロントとバックを構築してくれると言いましたが、今回はNuxt.jsでフロントを構築するところまでやっていきます。5〜10分ぐらいでさくっと作っていきましょう。
※Node.jsインストール済前提で進めます

Nuxtプロジェクトの作成

公式ドキュメントにしたがってプロジェクトを作成。

$ npx create-nuxt-app nuxt-amplify-sample

create-nuxt-app v3.2.0
✨  Generating Nuxt.js project in nuxt-amplify-sample
? Project name: nuxt-amplify-sample
? Programming language: JavaScript
? Package manager: Npm
? UI framework: Bootstrap Vue
? Nuxt.js modules: (Press <space> to select, <a> to toggle all, <i> to invert selection)
? Linting tools: ESLint, Prettier
? Testing framework: None
? Rendering mode: Single Page App
? Deployment target: Server (Node.js hosting)
? Development tools: (Press <space> to select, <a> to toggle all, <i> to invert selection)

この時点でローカル表示できることを確かめてください。

Amplify CLIインストールとユーザー作成

Amplify CLIをインストールします。

$ npm install -g @aws-amplify/cli

amplify -v でバージョンが確認できたらOKです。
続いてAmplify CLIで使用するユーザーを作成します。既存のユーザーを使う場合は不要です。

$ amplify configure
Follow these steps to set up access to your AWS account:

Sign in to your AWS administrator account:
https://console.aws.amazon.com/
Press Enter to continue

Specify the AWS Region
? region:  ap-northeast-1
Specify the username of the new IAM user:
? user name:  amplify-cli-user
Complete the user creation using the AWS console
https://console.aws.amazon.com/iam/home?省略
Press Enter to continue

Enter the access key of the newly created user:
? accessKeyId:  ********************
? secretAccessKey:  ****************************************
This would update/create the AWS Profile in your local machine
? Profile Name:  amplify-user

対話形式でユーザーが作成されます。途中AWSコンソール画面が開くので、そこでユーザーを作成します。作成後、認証情報をcsvダウンロードしてコマンドラインに打ち込んだら終わりです。これでこのユーザーの情報が~/.aws/ のcredentialsとconfigに追記されます。

Amplify初期設定を行う

対話形式でamplifyの初期設定を行います。

$ cd [作成したプロジェクト]
$ amplify init
Note: It is recommended to run this command from the root of your app directory
? Enter a name for the project NuxtAmplifySample
? Enter a name for the environment dev
? Choose your default editor: Visual Studio Code
? Choose the type of app that you're building javascript
Please tell us about your project
? What javascript framework are you using vue
? Source Directory Path:  .
? Distribution Directory Path: dist
? Build Command:  npm run build
? Start Command: npm run start
Using default provider  awscloudformation

For more information on AWS Profiles, see:
https://docs.aws.amazon.com/cli/latest/userguide/cli-multiple-profiles.html

? Do you want to use an AWS profile? Yes
? Please choose the profile you want to use amplify-user

無事成功するとamplifyディレクトリとamplify.jsonが作成されます。 設定したビルドコマンドはamplify/.config/project-config.jsonに記載されています。（これが何に使用されているかはわからないです。変な値を設定してもビルドできたので、、）設定したユーザー情報はamplify/.config/local-aws-info.jsonに記載されています。
この時点でAmplifyのコンソール画面からプロジェクトが作成されたことを確認できます。 またcloudformationでスタックが作成されたことも確認できます。このスタックによってS3バケットとIAMロールが作成されます。

Gitにあげる

ソースとしてはそろったのでGitにあげます。今回はGitHubを使用しました。Gitを使用しない方法もありますが、今回は割愛します。

デプロイする

Amplifyのコンソール画面からGitと連携させてデプロイしていきます。画面の通りに入力していきます。 このままのビルド設定だとaccess diniedとなってしまいますが、いったんこのまま進めます。

ビルド設定はamplify.ymlに記述されています。amplify.ymlをプロジェクトの中にファイルとして存在させておけばその設定が読み込まれます。今回はファイルを作成していないのでコンソールから修正しています。詳しくは公式ドキュメントを参照してください。
ディレクトリがdistに設定されていなかったのでそこを修正していきます。 修正したのちに再ビルド。 ビルド完了したら、アクセスして確認。 できた！hello worldではありませんが、初期表示ができたのでめでたしめでたし。
ではまた！

ドメイン駆動設計入門をまとめてみる

ドメイン駆動設計入門を読んだのでざっくりですが記事にまとめます。
仕事でご一緒したオブジェクト指向設計好きのベテランエンジニアさんがわかりやすいと薦めていたので読んでみました。ドメイン駆動設計自体なにも知らなかったですが、読んでみて考えは理解できたかなと思っています。

ドメイン駆動設計とは

本では、ドメイン駆動設計=「ドメインの知識に焦点をあてた設計手法」と書いてあります。 まずドメインってなんやねんって話。自分的な解釈としては
ドメイン（領域）：
作るシステムのターゲットとする世界。物流なら物流、小売なら小売の世界のこと。

なにかしらの課題解決のためにシステムを作るんだから、その対象の世界について勉強して知識を蓄えますよね。ドメイン駆動設計の思想は、課題解決のためにその対象の世界（ドメイン）について、解決に必要な知識をつけてコードに反映させていこうぜってこと。まぁ考えとしては当たり前ですよね。技術屋さんあるあるの技術に寄りすぎた開発をするなよってことですね。

ドメイン駆動設計のストーリー

もうちょっと詳しく、どういう流れで設計をするものなのかというとこんな感じです。

①ドメイン内の世界をオブジェクトで表現する（ドメインオブジェクト）

対象の世界（ドメイン）をどうプログラム上で表現するかって話ですが、オブジェクト指向設計なのでもちろんオブジェクトで表現します。ドメイン内には人やら物やら考えやらが存在します。物流でいったら、倉庫や運搬する人や利用者などです。これらのドメイン内に登場するものをオブジェクトで表します。本ではこれをドメインオブジェクトと呼んでいます。

②ドメインオブジェクトを使って課題解決

システムを作るってことはドメイン内になにか課題があるってことですよね。ドメインオブジェクトでドメイン内の世界が表現できたので、これらを使っていざ課題解決をしていきましょうって話です。

感覚的にはおままごとみたいな感じですかね。実世界の家とか人間とかをおもちゃという形で表現して、子供がその表現された世界で遊ぶ。ちょっと違うか笑

ドメイン駆動設計はなにがいいのか？

本の中ではドメインをしっかり分析して設計開発を行うので、ソフトウェアの変化に対応しやすく、拡張がしやすい的なことが記載されていました。仕事でドメイン駆動設計が意識されたコードを複数読んでいるので、本を読んで感じたことと合わせて個人的にいいと思ったところを記述します。
それぞれのクラスの責務が明確になっていてコードが読みやすいです。後述しますがドメインオブジェクトならドメインブジェクト、リポジトリならリポジトリと責務が明確です。なのでどこに何が書いてあるのかちゃんと読まなくてもおおよそわかります。まぁコーディングのあるべき当然の姿なのかもしませんが。最初はクラスが多くて読みづらいと感じましたが、慣れた今では読みやすいと感じます。

本で解説されているパターン

この本では「知識を表現するパターン」と「アプリケーションを実現するパターン」の大きく2つに分けられます。「知識を表現するパターン」では、ドメインオブジェクトをコード上どうやって表現するかについて解説しています。「アプリケーションを実現するパターン」はドメインオブジェクトを使って、どう課題を解決するコードを書いて行くかを解説しています。多すぎてまとめきれないので超ざっくり記載します。本では割と細かくコーディング方法や注意点が記載されているので知りたい方はぜひ買ってみてください！

知識を表現するパターン

ドメイン内の世界をどうやってオブジェクト化していくのかって話です。まぁオブジェクト化するので簡単に言うと、対象のものをクラスで表現してあげるってことですね。例えばユーザー名をオブジェクト化する場合は単純にUserNameというクラスを作るだけです。で、ユーザー名に関するルールや制約はそのクラスにロジックとして集約する感じ。（例えばユーザー名は3文字以上しか設定されないようにするなど。）
オブジェクトの表現パターンとして「値オブジェクト」「エンティティ」が紹介されています。

アプリケーションを実現するパターン

ドメインオブジェクトを使ってどうプログラムを組んでいくかって話です。紹介されているパターンをざっと記載します。
・リポジトリ
オブジェクトのインスタンスを永続化するためにDBなどに接続するためのもの。ドメインオブジェクトと切り離してコーディングすることで、DBが変わるなどしてもここだけ直せばOKだよねって話。
・アプリケーションサービス
ドメインオブジェクトを操作するためのオブジェクト。操作とは主にCRUD（Create,Read,Update,Delete）処理などを指します。 ドメインオブジェクトの操作はこのオブジェクトに寄せようっていう話がされています。
・ファクトリ
複雑なオブジェクトの生成処理がある場合に、そのオブジェクトの生成処理を行うためのオブジェクト。オブジェクトの複雑な生成処理がある場合、コンストラクタに処理を記載すると思います。コンストラクタを複雑にするくらいなら、ファクトリという生成専門のオブジェクトを作って、生成されるオブジェクト自体のコンストラクタはきれいにしましょうって話。

感想

なんとなく頭で考えていたことをちゃんと体系立てて学べたなと感じました。これを読んで新しい考えがたくさん手に入るというよりは、頭の中を整理してもらえる感じ。プログラミング習いたての人が読んでも少し吸収するのは難しいかなといった印象です。何回かオブジェクト指向でプログラムを組んだことがあると、すんなり入ってくるかなと思います。個人的には設計云々の本は読んだことがなかったのでとても勉強になりました。ではまた！

今更去年いったアメリカ一人旅を振り返る

2019年10月、1週間の休みを利用してアメリカに一人旅をしてきました。 ラスベガス、グランドキャニオンあたりに移動含め8日間くらい。 一人旅といっても中2日、グランドキャニオンツアーに参加したので完全一人旅ではないです。 一人旅ならではの思い出もかなりできたので、印象に残っているエピソードを今更ながら記します。

アメリカ人との沈黙の30分

このアメリカ旅での一番の目的、ラスベガスでスカイダイビング。 めちゃめちゃワクワクしてスカイダイビング 場に行く。参加者は中国人の友達2人組、アメリカ人カップル、アメリカ人の友達3人組、自分。（英語話せないの俺だけ泣）まずアメリカ人3人組と僕が呼ばれ、着替えをする。準備をしていざ出発なのだが、ヘリコプターは1台でそこにインストラクターと飛ぶ人のペアが2組乗る。つまり飛ぶ人2人はヘリコプターが帰ってくるまで待たなければいけない。先に3人組のうち2人が出発したので、僕とアメリカ人の二人きりに。 歳は同じくらい。アメリカ人がかなり気を使ってくれて色々質問してくれた。自分も頑張ってなんか話さなきゃと思い、出てきた質問が「Do you play sports?」大学院まで出たのに、英語の論文読んでたのに、こんなんしか出てこない。結局30分近く待ったのだが、後半はほぼ沈黙。英語話せたらもっと楽しかったなぁと思いつつ、出川ってすげぇなぁって思った。

アメリカンジョークからのかっこよすぎるインストラクター

ヘリコプターが帰ってきていざ自分の番。一緒に飛んでくれるインストラクターと対面。この時の会話がかっこよすぎる。
インストラクター：Can you speak English?
　　　　　　　僕：Little...😖
インストラクター：OK! Las vegas for the first time?
　　　　　　　僕：Yeah!
インストラクター：Skydiving for the first time?
　　　　　　　僕：Yeah!
インストラクター：Oh, me too!!
　　　　　　　僕：No no no no 😅
インストラクター：Nice English👍
　　　　　　　僕：😊😊😊

もちろんスカイダイビングはめちゃめちゃ楽しかった。

ツアーで友達ができる

2日間の日本人グランドキャニオンツアーに参加。参加者はおばちゃん3人組、30代夫婦、20代カップル、30歳男性、自分。一人で参加するやつなんていないと思っていたので、うれしくて30歳男性に速攻話しかける。2日間ずっとその人とご飯を食べたし、星も見たし、2ショットもかなり撮った。参加者ほとんどと仲良くなれ、これも一人旅の醍醐味かなと思った。グランドキャニオン周りはいろいろすごいところがあるので2日間かけて行くことをおすすめする。

道端でアメリカを感じる

ラスベガスのホテルからアウトレットに向かう。バスで行けたけど、特にすることもなかったので1時間以上かけて歩いて行くことに。このアウトレットに向かう道がなんともアメリカっぽい。でかい。この道を歩きながらQueenを聞いてたんだけど、俺アメリカ来てるやん感がすごい。Queenがイギリスとかそんなん関係ない。アメリカに来た自分に酔いしれてた。Don't Stop Me NowとBicycle Raceはまじでテンションあがる。書く程のことじゃないかもだけど、なんかここがかなりいい思い出として残ってる。

台風で空港足止め

ラスベガス→ダラス→成田で帰る予定だったが、ダラスについて待っているときに成田への飛行機が飛ばないことが発覚。2019年10月、関東が台風でかなりダメージを受けたがちょうどその日だった。空港の状態がよろしくないらしく、次いつ飛ぶのかもわからない。とりあえずやべぇと思いながら、航空券がアメリカン航空だったので、その窓口に向かう。列にならぶと日本人らしき人が前にいたのでとりあえず話しかける。どうやら同じ境遇の日本人がかなりいたので、いろいろ情報交換をする。こういう時、人ってあったかいよね。最初取れたチケットが5日後とかで絶望していたが、教えてもらったアプリを駆使してなんとか1日の空港泊だけで帰ることができた。空港泊の間、出張できていた36歳男性と夜飯がてらビールを飲んだ。他にもいろんな人と話せた。当時は最悪だと思ったけど、今振り返れば面白い経験だった。

最後に

いろいろ失敗もありましたが、また海外一人旅にいきたいと思えるぐらいに楽しかったです。アメリカは最高でした。人生についていろいろ悩んでいた時期でしたが、そんなことどうでもよく感じさせるほど圧倒的なスケールでした。またいつか行きたいです。
僕は知らない女性のアメリカ一人旅記事を見て、アメリカに行くことを決めました。この記事もだれか一人でも響いたら嬉しいです。ここまで読んでくれてありがとうございました。ではまた！

ベンチャーに転職して4ヶ月たった感想

一部上場IT企業からベンチャーに転職して4ヶ月が経ちました。ほぼリモートワークですが実際に入社してみてわかってきた部分もあるので、つらつらと書いていきます。

どんな会社に入社したか

ざっくり言うとAI系の会社で設立約2年です。僕はAI経験がまるでないので、普通のエンジニアとして採用してもらいました。ちょっと特殊な会社で設立2年ですが、経営は割と安定していてベンチャー特有のガツガツ感はほぼないです。ベンチャーらしさもちょっと体験してみたい部分はあったので、そこはちょっと残念。

入社した理由

まずベンチャーを希望した理由は、前の記事にも書きましたが以下3つ。

• インフラ〜フロントまで自分で開発してみたい
• 経営者の近くで、会社の動く仕組みを吸収したい
• 会社が組織として成長していく姿をみたい

その中でも今の会社を選んだ理由は以下2つ。

• 初心者でもAIに携わらせてもらえそう
• エンジニアだけでなく、サービス企画、コンサルチックなことも経験できそう

入社してからやったこと

既存コードの引継ぎ、新しいサービスの設計から構築までをやらせてもらいました。AI自体はまだ触っていないです。前職とやっていること自体がまるで違うので、最初の方は業務時間外もずっと勉強していました。その甲斐あってか評価はいただけたので頑張ってよかったです。

よかったこと

エンジニアとしてかなり自由にやらせてもらっているのでその点はありがたいです。個人的に勉強したことをすぐに生かせるので、やっていて楽しいです。大きい企業だとわりと制約が多いと思うので、ベンチャーならではかと思います。僕は勉強することが好きで、それを生かせるとかなり楽しく感じるので、本当に来てよかったと思っています。
また前職と違っていろいろと仕組みが定まっていないので、何をするにも自分で考えて行動することが多いです。めんどくさいと思う人もいるかもですが、これは僕にとってはいい点です。

わるかったこと

ガツガツ感がないことです。ベンチャーらしくスピーディにやっていきたいですが、結構ゆっくりしています。前職の方がスピード感、プレッシャーはありました。企業文化からしょうがないことかもですが、この辺はできれば変えていきたい。
エンジニア面では、人から吸収できる点が少ないと感じます。前職の場合、人が多くいろんな分野に強い人がいました。今の会社では個人開発が多く、リモートも相まって全て自分で勉強しなければなりません。まぁ覚悟の上きたのでいいですが、やっぱり人から吸収したいなとは思います。

まとめ

4ヶ月働いてみましたが今のところ来てよかったと思っています。もちろん悪い点もありますが、自分が望んだ方向に動いていることは間違い無いので。初めて転職という行動を起こして、プライベートでも行動をするようになってきました。このブログもその一つです。ということで、ちょっとずつ人生が楽しい方向に転がってきている気がするので、引き続き頑張ります。

Lambda+API Gatewayで複数画像を連携する

API Gatewayを用いて複数画像を連携したい場合の処理方法について備忘録として記しておく。 クライアントから1つの画像を受け取り、3種類の色変え処理をした画像を返すといった処理をサンプルコードとして記述する。

サンプルコード

この画像を

次の3パターンに色変えする。

APIとして複数画像を連携する場合は、クライアント、サーバ間でbase64にエンコードした形でbodyに埋め込めばいい。lambdaのコードがこちら

import base64
import json

import cv2
import numpy as np

def handler(event, context):
    #パラメータを受け取る
    body = json.loads(event['body'])
    file_type = body['file_type']
    image_base64 = body['image_base64']

    #base64のデータをcv2のBGRデータに変換
    nparr = np.fromstring(base64.b64decode(body['image_base64']), np.uint8)
    bgr = cv2.imdecode(nparr, cv2.IMREAD_COLOR)
    
    #BGRからHSVに変換
    hsv = cv2.cvtColor(bgr, cv2.COLOR_BGR2HSV)
    
    #色変え処理を実行
    chg_hue_ptns = [30,130,160]
    chged_col_imgs = []
    for chg_hue_ptn in chg_hue_ptns:
        hsv_chg = np.copy(hsv)
        hsv_chg[:, :, 0] = np.where((hsv[:, :, 0] >= 90)&(hsv[:, :, 0] < 100),
                                    chg_hue_ptn,
                                    hsv_chg[:, :, 0])
        chged_col_imgs.append(cv2.cvtColor(hsv_chg, cv2.COLOR_HSV2BGR))
    
    #BGRをbase64に変更
    base64_imgs = []
    for chged_col_img in chged_col_imgs:
        result, dst_data = cv2.imencode('.'+file_type, chged_col_img)
        base64_imgs.append(base64.b64encode(dst_data).decode('utf-8'))
    
    return {
        'statusCode': 200,
        'body': json.dumps({'imgs':base64_imgs}),
        'headers': {'Content-Type': 'application/json', 'Access-Control-Allow-Origin': '*'}
    }

API Gatewayのペイロードサイズは最大10Mなのでその点は注意が必要。 docs.aws.amazon.com

参考

[Python3] 画像をBase64にエンコード、Base64をNumPy配列へ読み込みOpenCVで処理、画像データをBase64に変換 - Qiita

AWS Lambda (Python 3.7) 向けに OpenCV 3.4 & NumPy の Lambda Layers をビルドする - Qiita

一部上場企業からベンチャー企業に転職した話

はじめに

もう3ヶ月ほど前の話ですが、一部上場のIT企業を退職しました。 新卒で入社してからちょうど3年です。 ITコンサルを謳っている会社で、僕自身は小売業の基幹システムをつくるプロジェクトで設計〜運用まで経験させてもらいました。 イメージ的にはSIerがやっている仕事に近いのかな？と思います。

そもそも前職になぜ入社したか

いろんな理由はあったかと思いますが、パッと思い出せるのはこんな感じです。

• なんかワクワクする
• IT技術がしっかり身に付きそう
• 離職率の高さ故、いつかやめるという先の見えなさが面白そう

上2つはよくある理由ですが、変なのは3つ目ですかね。 いわゆる大手企業は福利厚生などがしっかりしていて、特別な理由でもないかぎりやめないんだろうなぁと就活当時は漠然と思っていました。 未来が見えたとたん、なんかおもろなって思うようになり、先が見えないことに魅力を感じ始めました。 今時点でもその考えは変わらないです。

実際に働いてみてギャップはあったか

半分想定通りで、半分は想定外でした。

入社後もワクワクしたか

研修時代はシビアな競争下で割とドキドキワクワクしてました。配属後はプロジェクトの都合上、そんなにワクワクはしなかったです。別プロジェクトの同期の話を聞いて面白そうだなと思うことはありました。

IT技術は身についたか

自分としては、想定の半分も身につかなかったかなと。IT未経験入社でとても技術力が高い先輩方もいらっしゃったので、会社のせいというよりは置かれた状況と、個人のやる気次第だったかなと。僕のプロジェクトでは社内フレームワークで開発していました。良くも悪くも自由度がなく、大した技術がなくても開発できるようになっていました。それでやる気を失ったのが伸びなかった原因です。家で学習を進めなかった自分のせいです。

なぜやめるのか、なぜベンチャーか

やめる理由は大きく3つです。

• 10年先を想像して続けていたいと思えなかった
• 大きい会社で働くことに魅力を感じなくなった
• 別の人生にチャレンジしてみたくなった

とあることがきっかけで、今後の自分の人生を見つめ直し始めました。 今後一生企業で働き続けるのかーと思うと、なんとなく楽しい気持ちにはなれず。働きたくないというよりは企業で働くという選択肢しかないという状況になりたくなかったって感じですね。会社で働いたっていいし、別の方法で稼いだっていい。その時の気まぐれで生きていたいと思っています。
やめた後なにするかでは結構悩みました。海外に住んでみる、フリーランスエンジニアになる、ベンチャー企業で働く。このあたりがなんとなく選択肢になってました。
一番ワクワクしたのは海外に住んでみるだったのですが勇気が出ずチキりました。それで次にワクワクしたベンチャー企業への転職を選びました。ベンチャーを選んだ理由はこんな感じ。

• インフラ〜フロントまで自分で開発してみたい
• 経営者の近くで、会社の動く仕組みを吸収したい
• 会社が組織として成長していく姿をみたい

さいごに

給料そこそこの一部上場企業から設立まもないベンチャーに転職したので給料はまぁまぁ下がりました。周りには驚く人もいたし、YouTubeとかでも転職で給料は下げるななどとよく言われています。正直この選択が合っているかということに自信はないです。まぁ結構悩んで出した決断なので揺らぎはしないですが、この決断が正解だったと思えるようにがんばります。ここまで読んでいただきありがとうございました！

監視初心者が「入門 監視」を読んでみた

こんな人におすすめ

「監視設定しなきゃだけど、そもそも監視ってなにするんだ？」って方におすすめです。

自分はとあるベンチャー企業で働いているのですが、職場の方から「監視設定入れておいてください」と言われ「ちょっ、えっ、、」と困り果てたので、オライリーの「入門 監視」に助けを求めました。

目次

• 第Ⅰ部　監視の原則
  • 1章　監視のアンチパターン
  • 2章　監視のデザインパターン
  • 3章　アラート、オンコール、インシデント管理
  • 4章　統計入門
• 第Ⅱ部　監視戦略
  • 5章　ビジネスを監視する
  • 6章　フロントエンド監視
  • 7章　アプリケーション監視
  • 8章　サーバ監視
  • 9章　ネットワーク監視
  • 10章　セキュリティ監視
  • 11章　監視アセスメントの実行

第Ⅰ部では監視でやってしまいがちなこと、あるべき姿を提示し、第Ⅱ部で各領域で具体的にどういった監視を行えば良いかを示してくれています。
個人的には第Ⅰ部はしっかり読んで、第Ⅱ部は興味あるところを重点的に読むでいいんじゃないかと思います。
（ネットワークとかセキュリティに弱いので9、10章は正直入ってこなかったです、、泣）

個人的な解釈ですが、刺さったものをつらつらと書いていきます。

1章　監視のアンチパターン

ツール依存になるな
万能なツールなど存在しない。自分らの目的を満たすように必要あらばツールをつくる。

監視の仕組みは全員でつくれ
サーバならサーバ、アプリならアプリ、それぞれを構築した人がホットスポットを知っているはず。
一人が監視の仕組みを作らず、作った人全員で仕組みを作る。

動いているとはどういう意味かをちゃんと定義せよ
HTTPだったら200が返ってくることなど、どうあればシステムが動いているのかを定義する。
その上でちゃんと動いているかのチェックを行う。

2章　監視のデザインパターン

ユーザー視点での監視を行う
1章の通り、ユーザーにとって動いているとは何かを定義し、それを検知できる仕組みをつくる。

監視の仕組みは作るのではなく買え
作るコストを考えるとSaaSを利用したほうが安くすむよ？なにより自分ら監視について詳しくないでしょ？
ってことでした。仰る通りです。。

監視の仕組みは改善をつづけよ
Google、Amazonだっていきなり素晴らしい監視の仕組みが作れたわけではない。
使われなくなった仕組み、新たに作られた仕組みがたくさんあるのだ。

3章　アラート、オンコール、インシデント管理

アラートは即時対応が必要なもののみにせよ
即時対応が必要なものはSMS、PagerDutyなどのページャに、それ以外は社内チャットに送るのがいいよとのこと。ツールはなんであれ、即時対応の要否で分けるのは自分の運用経験からも納得ですね。

人間の判断がいらないものは自動復旧できるようにする
即時対応が必要なもののみアラートすると書いたが、それはその対応に人間の判断が必要な場合に限る。
手順通りにやれば解決できるものは自動復旧できるようにすべき。

5章〜11章

それぞれの領域で具体的な対応が書かれていましたが、自分は5章、6章が印象に残ったのでそこについて。
経営者目線でシステムを監視する
顧客はサービスを使ってる？サービスは成長してる？儲かってる？
経営者はこういったことを気にするが、これを知るための情報を用意するのも監視の役目だそうです。

画面描画が1秒遅れると顧客満足度は16%下がる
らしいです。まぁこれは自分も1人のユーザーとして感じることですが。
フロントの監視は疎かにされがちですが、大切にねとのことです。

まとめ

この本を読んだからといって、よっしゃ監視イケそうだな！とは正直思えませんが、仕組みを作っていく上で考えの土台にはなってくれるかなと。
2章に書いてあったけど、試行錯誤で1歩ずつがんばっていきます。