mutao.net

いわゆる雑記。

Podの終了

kubernetes.io

API server内のPodは、猶予期間を越えるとPodが「死んでいる」と見なされるように更新される。 削除中のPodに対してkubectl describeコマンドを使用すると、Podは「終了中」と表示される。 Podが実行されているNode上で、Podが終了しているとマークされている(正常な終了期間が設定されている)とkubeletが認識するとすぐに、kubeletはローカルでPodの終了プロセスを開始します。 Pod内のコンテナの1つがpreStopフックを定義している場合は、コンテナの内側で呼び出される。猶予期間が終了した後も preStopフックがまだ実行されている場合は、一度だけ猶予期間を延長される(2秒)。 備考: preStopフックが完了するまでにより長い時間が必要な場合は、terminationGracePeriodSecondsを変更する必要があります。 kubeletはコンテナランタイムをトリガーして、コンテナ内のプロセス番号1にTERMシグナルを送信する。 備考: Pod内のすべてのコンテナが同時にTERMシグナルを受信するわけではなく、シャットダウンの順序が問題になる場合はそれぞれにpreStopフックを使用して同期することを検討する。

久々に読んだら全然わからん...となってしまったので思い出しながらメモ。

終了処理はSIGTERM、SIGKILL(猶予期間terminationGracePeriodSecondsを超えた場合)の順に実行される。また並行してServiceからの除外処理は非同期で行われる。

Serviceの除外処理とは、kube-proxyによりiptabelsが更新されることにより、新規の接続がなくなること。

終了開始とともにServiceから除外されないため、終了処理中にServiceからの新規接続を受け入れてしまう期間が発生してしまう。

それを防ぐためにpreStopを設定する。

preStopを設定することにより、SIGTERM処理の前に任意のコマンド、例えばsleepを入れることにより一定期間待機させることが可能。

SIGKILLはterminationGracePeriodSecondsを超えたときに送信される。

terminationGracePeriodSecondsはデフォルトで30秒。もしpreStop処理がterminationGracePeriodSecondsを超えてしまうような設定は避けるべき。

図示するとこうなる。

AWSの薄い本 IAMのマニアックな話

1章 AWSとIAM

  • 認証と認可
  • AWSアカウントについて
    • AWSアカウント(ルートユーザ)
    • IAMユーザ

docs.aws.amazon.com

2章 IAMの機能

  • IAMの機能
  • IAMユーザ
    • ID と PASSWORD
    • アクセスキーID と シークレットアクセスキー
      • アクセスキーの発行は原則しない。必要なときに最小権限で発行する。
  • IAMユーザの発行単位
    • 実際に誰が利用していたのかを把握するため、利用者毎・プログラム・ツール毎に発行する
  • IAMグループ
    • 同一の役割をもつユーザをグループ化し、権限を付与できる。
    • Admin, Developer...
  • IAMロール
    • AWSサービス、アプリケーションに対して操作権限を付与する
    • IAMユーザを割り振れない場合等に使う
  • パーミッションバウンダリー
    • IAMユーザ、IAMロールに対するアクセス権限
    • 付与した権限とバウンダリーで許可した権限と重なりあう部分のみ有効な権限として動作する。
    • バウンダリーで許可していない場合は、IAMユーザ、IAMロールで権限を付与しても操作することができない。

第3章 IAMチュートリアル

  • GUIでの操作の解説
  • IAMの許可・拒否ポリシーの挙動
    • 明示的なDeny > 明示的なAllow > 暗黙的なDeny(デフォルト)

第4章 IAMポリシーのデザインパターン

ホワイトリストパターン

  • 許可する権限のみを付与
  • 他はデフォルトの挙動で暗黙的なDenyで制限される
  • メリット
    • 必要最小限の権限のみを付与するためセキュリティにおける信頼性が高い
  • デメリット
    • 事前に付与する権限が決まっていないと付与することができない
    • 探索的に開発を進めていく場合、都度、権限付与する必要があり、IAMポリシーを管理する手間がある
  • 業務や運用設計が確率している場合、高いセキュリティを求められる場合に有効

ブラックリストパターン

  • 許可してはいけない権限を剥奪する
    • ex. NotActionでIAMの権限以外の権限を許可した後にパスワード変更等の権限を明示的にAllowで設定する。
  • メリット
    • 禁止事項のみを定義するだけでいいのでIAMポリシーの設計・設定が最小でよくなる
    • 利用者は高い自由度を持つことができる
  • デメリット
    • NotActionで指定するため、AWSに新しいサービスが始めると自動的に新しい機能が使えるようになってしまう。
  • AWSの権限は暗黙的なDenyのため、新しいサービスを使いたくても権限がなく、すぐにサービスを利用したくても使えないが、ブラックリストパターンではすぐに利用できる。
  • 探索的な開発を行う場合等に適している。

ハイブリットパターン

  • ホワイトリストブラックリストパターンの組み合わせ
  • メリット
    • AWSの定義済みポリシーと作成したブラックリストを組み合わせることで最小の労力でポリシーを作成することができる。
    • ポリシーの組み合わることで権限の設定するため個々のポリシーはシンプルになる

第5章 IAMグループのデザインパターン

  • 以下の2パターンには機能的な優劣は存在せず、運用面で組織やチームにあったものを選択すればよい
  • 複数のグループに所属するパターン
    • 必須の全ユーザ向けIAMポリシーを持つIAMグループに所属させ、開発者向けまたは運用者向け等の役割毎IAMグループに所属させる。
  • グループ内に複数のポリシーを設定するパターン
    • ユーザーが一つのグループに所属するという前提に権限を管理する
    • 1つのグループにしか所属しないため、シンプルさがある

第6章 IAMとセキュリティ

  • IAMのベストプラクティスにはIAMだけではなくAWSアカウントの管理を含めて記載されている。

docs.aws.amazon.com

  • すべてのIAMユーザにMFAを設定しておくこと
    • 将来的に特権ユーザーになる場合があるため、初期段階ですでにMFAの設定をしておく
  • Lambdaリソースベース権限
    • AWSリソースへのアクセスはIAMポリシーで管理されていて、Lambda関数の実行ロールとして紐付けることができる。
    • Lambdaはリソースベースのポリシーを利用することができ、リソース毎に他のアカウントに使用許可を与えることができる
    • リソースベースのポリシーはIAMの権限を利用せずともアクセス権限を得られることになるので最小権限を付与することが望ましい
  • インターネット公開系の権限
    • EC2のように権限が多岐に渡るものはネットワーク系の操作を明示的に拒否する方法と併用するとよい
  • S3へのアクセス元権限はIAMポリシーを使って制限を行うよりも、S3側のバケットポリシーを使うとよい。
    • IAMでリソース制限をする際にはプライベートIPを使用することができないため、InternetGatewayを通らない場合は、VPCのIDを元に権限を付与する。
  • アクセスキーの原則禁止
    • アクセスキー・シークレットアクセスキーの流出防止策はあるものの、作らないに越したことはない。
  • Capital Oneは2019/7に1億人を超える個人情報の流出事件
    • WAFの脆弱性を利用してIAMロールのクレデンシャルを取得した。
    • 原因はWAFにあるものの、大きな権限をもったIAMロールが存在することがリスクとなる
    • IAMロールやバケットポリシーは最小権限にすること

第7章 IAMの運用

  • セキュリティ保持のために手間がかかる運用であればいつかは形骸化する
  • IAM運用の目的
    • AWSを安全な状態の保持
    • 維持するために手間がかからず、利用者によってセキュリティレベルの差異がでないように標準化する。
  • ツール・プログラム利用・関係者の洗い出し
  • AWSアカウント(ルートユーザ)は原則的に使用しない
    • アカウント作成後は、ルートユーザを使用せずとも支障がないような設定を行うべき
  • IAMユーザの管理
    • 最小権限の付与
    • 不要になったユーザーの削除
    • Croud Trailで利用状況のログを取得、Configで設定変更の監視をするなどして定期的にIAMユーザの棚卸しをすべき
  • 人間用のIAMユーザー
    • ユーザー毎に作成し、共有アカウントの作成は禁止
    • 異動や退職などの入れ替わりに応じて棚卸しルールを作成する
  • CLIやプログラムから利用するIAMユーザー
    • 人の出入りに関しては比較的わかりやすい
    • プログラムから利用されなくなったIAMユーザは観測しにくい
    • IAMユーザごとの担当者を明確化する
    • 最終利用日から一定期間過ぎたIAMユーザーは継続確認を行う
  • アクセスキーの管理とCLI
    • アクセスキーは限られたIAMユーザーのみで作成する
    • アクセスキーを作成するIAMユーザーの権限は最小にする
    • CLIでもスイッチロールは可能なため、必要な場合はIP単位でIAMユーザの制限をし、スイッチロールする
  • MFA未利用時に権限を制限し、MFA利用を促す
    • MFAを設定していない場合は、IAM以外の権限を拒否するポリシーをアタッチすることでMFAの設定を促す
  • マルチAWSアカウントでの運用
    • IAMユーザをそれぞれのアカウントで作成するのは手間がかかる
    • 踏み台のAWSアカウントを作成し、そのアカウントでIAMユーザーを作成ののちにスイッチロールすることで手間が省ける

第8章 IAMとCloudFormation

  • CloudFormaion等のIaCでAWSアカウントを管理しておけば手間を省き、人的なミスを防ぐことができる

第9章 IAMのテンプレート集

  • CloudFormationのテンプレートがあったが割愛する
  • 共通ポリシー
    • 自身のパスワードをMFAの設定権限
    • IP制限とMFA必須化のポリシー
  • 管理者グループ
    • 全権限の付与
    • 全ユーザからのSwitchRoleをされることを抑制するポリシー
      • ロールにスイッチ可能なユーザを記載するパターン
      • 特定ユーザーにスイッチロール可能な権限を付与するパターン
  • ネットワーク管理者グループ
    • VPC作成、VPN設定などのネットワーク、セキュリティグループ、ネットワークACLの権限を持つ
    • AWS管理ポリシーのNetworkAdministratorの利用すると必要な権限がほぼ網羅されている
  • 開発者グループ
    • 多くのリソース制御が必要
    • 本書ではPowerUserAccessとネットワーク権限、Lambdaの権限付与をしているが、組織に適したポリシーをアタッチすることが必要
  • オペレーターグループ
    • どこまでが職務範囲かに依存
    • AWSサポートに問い合わせが必要な場合は、AWSSupportAccessを付与する
  • 経理担当者グループ
    • BillngにアクセスするためのAWS管理ポリシーをアタッチ
  • お一人様AWS(個人開発等)
    • Admin権限を普段扱いせず、参照権限のみを付与
    • 必要に応じて管理者ロールにスイッチロールするのが安全

第10章 IAM以外のAWSサービスの活用

  • AWS Organizations
    • AWS利用料金の一括請求
    • 組織内のAWSアカウントに対するポリシーコントロール
    • マスターアカウントで設定したポリシーは個々のアカウント単位で打ち消すことはできない
  • CloudTrailとConfig
  • 監査可能な状態にする
  • 誰いつAWSを操作し、リソースがどのような状態になったのかを把握できる状態

CloudTrail

  • 誰がどの操作を行ったのか実行履歴ログを取得することができる

Config

  • AWSリソースがどういう状態か、状態に対してどのようなアクションをするかを設定できる
  • ex. EC2インスタンスにタグでNameをつけることを必須化する運用ルールを策定し、それを満たしていない場合、強制的にシャットダウンさせる

GuardDuty

  • 驚異検出と継続的なモニタリングができ、それに対する防御を機械的に実行する

ControlTower

  • 複数のアカウントの設定及び管理するサービス

SecurityHub

  • 複数のアカウントの状況を一括してモニタリングするサービス

mutaonet.hatenablog.com

Security Hub Orgnization

Security Hub

OrganizationでSecurity Hubを有効にしてみました。

SecurityHubの有効化はAWS Configの有効化が必須なのが注意。

検出結果はChatbotを使用してSlackに通知している。

docs.aws.amazon.com

構築はほとんどTerraformで行った。

registry.terraform.io

Chatbotはawscc providerを使用すれば設定できますが、ChatbotをSlackのWorkspaceに招待することができず、AWS Consoleから操作しました。

もしかしたら見逃しているだけかも...

registry.terraform.io

適用したルールセットはSecurityHubを有効化したときにデフォルトで設定される以下。

Slackへの通知は以下のように行われる。

引用

検出結果1つにつき1件のコメントが通知されるので、場合によっては大量に通知がくる。

上位のSeverityだけをフィルタリングをEventBridgeのルールで設定できるので、絞っておいたほうがようさそう。

Security Hubの実行スケジュールは12時間毎に定期的に行われるため、対処しない限りは検出される。

一応、一度しかSlackへ通知しないといったフィルタリングもできるが、一度見逃したらアウトという感じになるのでやめたほうがいいと思う。

困ったこと

EventBridgeのデバックが難しい

Security HubというかEvent Bridgeの問題。

Event Bridge -> ルール -> 対象ルール名 -> モニタリング と遷移してCloudWatchから失敗していることが分かるが「Failed Invocations」以外の情報がない。

難しいというか不可能に近い。Event BridgeでECSタスクを発火させる場合はCloudTrailから失敗理由を終えたりするけど、今回のような構成では無理。

こういう場合はだいたいターゲット側(今回で言えばSNS)が原因のことが多いためそこから探っていく。

通知問題

大きく2つ。

  • 見辛い。

ConsoleからSecurity Hubを開けば何のルールで引っかかったのか、改善方法等が見れるがやっぱり見辛い気がする。

多分慣れ。通知のフォーマットが見辛いならLambdaを挟んでなんとかするしかない。

といっても見やすさは個人差があるのでそこまでやるメリットがあるかは不明。

慣れたほうがコスパよさそう。

  • 大量通知がくる

Severityでフィルタリングすればまぁ抑制することはできる。

が、大量のアカウントを作成していたり、AWS Foundational Best Practices に乗っ取らず運用してきた場合は中々難しい。

不要になったIAMはちゃんと削除してる?とか。そのレベルからの話もある。

ちゃんと運用しよう。に尽きる話ではある。が今後どうしていくか?というところにちゃんとリソースを投下しないと厳しい。

チーム内で一定期間専任をつけたりとかした方がいいと思う。

運用

公式のドキュメントにもあるように無効化したいルールが出てきた場合。

TerraformでもCosoleからでもできるが、その判断が難しい。

無効化するにあたっての根拠を整理し合意を取るというコストは割と大きいと思う。

(コストといってよいのか?)

隔週でMTGを行うとかが最初の1歩としてはよさそうな気がしている。

trivy入門してみる ①

trivy

github.com

Trivy (tri pronounced like trigger, vy pronounced like envy)

とのことなので「トリィヴィー」と発音するのが正しそう?

tfsecに続き、trivyを使ってterraformの静的解析をしてみる。

trivyは内部でtfsecを使って静的解析を実行している。

AquaSecurity社がtfsecを買収してtrivyに統合した結果が今とのこと。

www.aquasec.com

tfsecとの違い

親切なことにtrivyのドキュメントに書かれていた。

aquasecurity.github.io

実運用上で気になる差異はこんな感じ

  • Custom Policies
    • tfsecはyamlJSONで記述することができるが、trivyはRegoというフォーマットで記載する模様。

aquasecurity.github.io

  • Show Issue Lines

    • GHAで走らせたりするとissueを作成してくれるのだが、対象箇所をissueに記載してくれない模様
  • Filtering by Severity

    • うれしい機能。trivyはオプションとしてSeverityを指定してフィルタリングできる

さっそく使ってみる

  • scan対象のterraformコード
resource "aws_instance" "nginx" {
  ami                    = "ami-0218d08a1f9dac831"
  vpc_security_group_ids = [aws_security_group.default.id]
  instance_type          = "t3.micro"
  tags = {
    Name = "nginx_server"
  }

  user_data = <<EOF
    #!/bin/bash
    amazon-linux-extras install -y nginx1
    systemctl restart nginx.service
    EOF
}

resource "aws_security_group" "default" {
  name = "ec2"

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}
# CRITICALとHIGHのみをフィルタリング
$ trivy config --severity CRITICAL,HIGH . 

検出結果はtfsecと大差ない感じ。

tfsecのignoreがそのまま使える

内部的にtfsecを使っているのでそのままtfsecのignoreが使える。

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"] #tfsec:ignore:AVD-AWS-0107
  }

ただ振られているIDはtfsecとは異なる。

tfsecはv1.0.0からルールが変更されて「AWS000」等のlegacyな一見して分かりにくいIDから変更になっている。

ここはtrivyも追従してもらいたいなと思う。

github.com

avd.aquasec.com

Rego

Regoを用いてカスタムポリシーを記載できるのだが、個人的には分かりにくいと感じる。

学習コストはある程度存在している。

aquasecurity.github.io

そして注意したいのが、「Regoのカスタムポリシーはterraformに対応していない」ということ。

正確にはHCLは対応していてもTerraformHCLには対応していない。

ではどうするのかというと、terraform show -json で plan結果をJSONに起こしてOpen Policy Agentが読み取れる形式に変換してあげる必要がある。

terraformの静的解析ではtfsecに軍配が上がりそう・・・?

ただ、k8s manifest も Dockerfileにも対応しているtrivyに一本化したいという気持ちもあるのは確か。

tfsec入門してみる

セキュリティの機運が高まってきて、tfsecを導入しようというような動きがあるので事前に学習してみる。

github.com

  • tfsecのinstall
$ brew install tfsec
  • tfsecでチェックするためのterraformのコードを用意
    • ガバガバな全開放のセキュリティグループをnginxを入れたEC2インスタンス立てる
resource "aws_instance" "nginx" {
  ami                    = "ami-0218d08a1f9dac831"
  vpc_security_group_ids = [aws_security_group.nginx_security_group.id]
  instance_type          = "t3.micro"
  tags = {
    Name = "nginx_server"
  }

  user_data = <<EOF
    #!/bin/bash
    amazon-linux-extras install -y nginx1
    systemctl restart nginx.service
    EOF
}

resource "aws_security_group" "nginx_security_group" {
  name = "ec2"
  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}
  • tfsecを実行
    • 実際はもっと大量にでていますが、省略して一部のみ。
Result #1 CRITICAL Security group rule allows ingress from public internet. 
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 main.tf Line 22
───────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   22  │     cidr_blocks = ["0.0.0.0/0"]
───────┴───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
          ID aws-vpc-no-public-ingress-sgr
      Impact Your port exposed to the internet
  Resolution Set a more restrictive cidr range

  More Information
  - https://aquasecurity.github.io/tfsec/v1.19.1/checks/aws/vpc/no-public-ingress-sgr/
  - https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/security_group_rule#cidr_blocks
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

上記で引っかかっているのは↓のようです。

aquasecurity.github.io

aws-vpc-no-public-ingress-sgr というIDで管理されているみたい。

resource "aws_security_group" "nginx_security_group" {
  name = "ec2"
  ingress {
    from_port = 80
    to_port   = 80
    protocol  = "tcp"
    # tfsec:ignore:aws-vpc-no-public-ingress-sgr
    cidr_blocks = ["0.0.0.0/0"]
  }
}

ID指定で一旦無視させることでtfsecのチェックから除外することができる。

なお、workspace単位でignoreすることもできるので、途中からtfsecを導入してどえらい量の警告が出た場合は一旦workspace単位で無視してみると導入しやすそう。

危険な状態である。という認識を得るだけでも意味がある。

aquasecurity.github.io

どうせならGHAで動かしたいので探してみるといくつかあった。

github.com

今回はRun tfsec PR commenterを使ってみる。

name: tfsec-pr-commenter
on:
  pull_request:
  workflow_dispatch:
jobs:
  tfsec:
    name: tfsec PR commenter
    runs-on: ubuntu-latest

    steps:
      - name: Clone repo
        uses: actions/checkout@master
      - name: tfsec
        uses: aquasecurity/tfsec-pr-commenter-action@v1.2.0
        with:
          tfsec_args: --soft-fail --force-all-dirs
          github_token: ${{ secrets.GITHUB_TOKEN }}

ディレクトリを見てほしかったので、 --force-all-dirs を追加。

その他に使える引数は以下。 tfsec --help で出てくるのはだいたい使えるみたい。

aquasecurity.github.io

結果。自動でPRにコメントしてくれます。

中々使い勝手がよいです。デメリットは特にはないかな・・・?

キャリアについて考える

仕事でキャリアパスについて尋ねられたので考える時間をとってみた。

調べてみてわかったのが、他人のキャリアパスはほとんど参考にならない。

ネットではほとんどサクセスストーリーみたいな感じで紹介されているものが多いし、私がやりたいものと合致していなかった。

これまで

ざっくりとキャリア年表みたいなものを作った。

新卒時代の記憶とかはほとんど残っていない。

転換期となったのは3年目あたりだろうか。

多くの人が3年で辞めていく中、とてもいいプロジェクトにアサインされたのでそのまま5年目エンジニアとして前職でお世話になっていた。

プロダクト的にはとてもレガシーなもので同僚は私に同情していたが住めば都というかいざ働いてみると多くのことを学べた。

初めてリーダー経験を詰めたというのも大きいかもしれない。

結局前職で学べたいいことって?

藪蛇なタスクが大量にあった。

日々多くのタスクをこなしていくわけだが、「これは間違いなく地雷だろう」というタスクがいくつもあった。

考慮すべきことが多い、そもそもどうやってそのプロダクトが動いているのかわからない、テストコードはない。といった具合である。

ひたすらsshでサーバに入ってpsコマンドを叩く...みたいなこともやっていた。

リバースエンジニアリングという言葉を用いていいのかわからないが、まぁそんな感じ。

突けば間違いなく厄介なことになるのだが、職務上やらなければならない。

最初はいやいやな感じだったのが、以外と楽しい。

誰もやりたくないのは、Toilなものを除いて「誰もやれないことが多い」。

誰もやれないタスクをやることで、課題へのアプローチ方法や技術力が向上していったのだと思う。

技術力が高い人に囲まれていた

お客様のエンジニアがかなりレベルが高く学びが多かった。

エンジニアも細分化され、専門領域を持つ人が多く在籍していて日々成長ができた。

勿論、自社のメンバーやパートナーで構成されるチームメンバーも技術力が高い人が多く、ハードだけど学べることが多い、楽しい日々だった。

ビジネスサイドとの関係性

リーダーなのでお客様の企画の方とお話をする機会が多かった。

こういう機能を作りたい、ユーザーの回遊率を上げるためには、という施策にガンガン首を突っ込んでいけた。

GoogleAnalyticsを見てこういった改善方法はどうか、と提案したり初めての体験をできた。

成功したときは感謝され、失敗したときは一緒に悩む。

ビジネスサイドに関われるというおもしろさを感じることができた貴重な経験だった。

その反面で、リーダーという職務上で工数管理をしなきゃいけないのが苦痛だった。

でこれからは?

前職でアサインされていたプロジェクトにおける問題を解決する手段を求めていたらSREに行き着いた。

  • 環境構築
  • CI/CDパイプラインの構築
  • アラートの設定
  • 脆弱性対応
  • Toilの削減

などなど列挙したらキリがないが、DevOpsやSREに行き着くのは理解できる。

これらを踏まえると、私がやりたいのは「プロダクトを開発する」ことではなく、「安全・健全にプロダクトを開発できる仕組みづくり」がしたいんじゃないかなぁ。

ここに前職でおもしろさを感じていたビジネスサイドとの関係性やマネタイズも加えてみよう。

「安全・健全にプロダクトを開発できる仕組みづくり」を行って「素早くユーザーに価値を届けプロダクトを成長させたい」

プロダクトは使われなければなくなる。必死になってコードを書いたとしても価値を創出できなければ事業としてはクローズせざるを得ない。

だからビジネスは無視できない。事業あってのプロダクト、プロダクトあってのインフラ。

詰めが甘いが私はSREとしてのキャリアパス、というかビジョンが少しまとまったような気がする。

読書のススメ方

Notionを使って読書メモを残しておくようにした。

というのも転職をしてからというものインプットが多く、技術書も大量に読むことになったので読書メモをどう管理するか確立させたかった。

前はMacのNoteだったり、Typoraだったり、Dynalistだったり、Atomだったり...とうろうろとしていたけど、Notionでやっと落ち着きそう。

メリットととしては

  1. アカウントがあればどこからでも書けるし読める
  2. Markdownっぽい記述ができる
  3. Chrome拡張機能のNotion Web Clipperが優秀
  4. 自由度が高い
  5. 見栄えが良い

みたいな感じ。

asana.com

まずはNotion Web Clipperを使って読みたい本をAmazonで見つけたらギャラリーにためておく。

読み始めたらプロパティをいじって進捗管理をする。

プロパティを選択しているとフィルターをかけられるので読了したものや、優先度の高いものを表示できるようになるので良い

あとは章ごと読書メモを追記していくだけ。

読書会の準備も同じくNotionに移行していく予定