ツナワタリマイライフ

日常ネタから技術ネタ、音楽ネタまで何でも書きます。

AWS ECR の Image Scan 結果を Prometheus 形式で Export する OSS 作った

作った。

github.com

いい加減思っているのだけどタイトルが長くてつらい。

でも CloudProvider - Service - Items to export - prometheus - exporter

だとやむなし?

シリーズものです。Prometheus Exporter としては 4作目。

blog.chaspy.me

blog.chaspy.me

blog.chaspy.me

これは何

AWS ECR には Image Scan 機能があり、それを "Findings" として、脆弱性や Severity Level をみることができます。

dev.classmethod.jp

クラメソさんいつもありがとう。

解決したい課題

ECR Image Scan は便利だが、まぁかなりの量が出る。

で、Severity も Critical から Information level まで様々だ。

これが Repository ✖️ Image Tag 分あるというわけで、かなりの量になる。GUI でポチポチみるより、より簡単な方法で可視化したい。

また、Severity level で Filter したり、Repository で Filter して優先度をつけたりというコントロールができるようにならないかと考えている。

f:id:take_she12:20210131184547p:plain

工夫した点

工夫というほどではない(いつもの)

IMAGE_TAG 指定を必須にした

仕様の問題だが、IMAGE_TAG 指定を必須にしました。あと現状 Image Digest での Image 指定はサポートしていません。

ユースケースを考えても特定リポジトリに対応する特定の Tag だけ見れればいいはず&Image Tag を指定しての API Call はまとめてできないので、いっそ必須にしてしまった。

あとあとで触れるがパフォーマンスの問題があるので、Image Tag で絞り込まないと結構キツい。

Pagination Support

まぁ数が多いのでちゃんと追いかけるようにした。

NextToken があれば Set、なければ終わるとすればいいだけなので楽だった。

github.com

今後改善する点

Performance

地獄の For Loop をキメてしまっているので、API Call は並行で処理できるようにしてパフォーマンスを改善する

Error Handling

この部分を switch 使えだの errors.As を使えなどと linter が言ってくるんですが

github.com

正直どうすればいいかわかってない。型アサーションは errors.As でできそうだけど、そのあと Error Name? Code? ごとに例外をキャッチしていくのをどうすればいいのかわかってない。誰かペアプロしてください。

Attributes の取得

Attributes が Key と Value をそれぞれ持った struct の List なんだけど

ecr - Amazon Web Services - Go SDK

こんな風にぐるぐるまわして switch case で取らないといけないのマジ?ってなっている。でもそんなもん?

github.com

感想

RDS のやつよりは面倒でした。あとこれもまた metric 送って眺めて味ってみないと役に立つかどうかはまだわかりません。

次回作

aws-rds-max-connections-prometheus-exporter

RDS の max connections を metric として送る。

現状、Datadog Integration ではこれらは取れていない。

いまは Connection の Anomary Detection のAlert をつけているが、False Positive に飛んできたりする。

で、max connections は parameter group の中にあってそれは API で取得できるんだが

docs.aws.amazon.com

  • MySQL: {DBInstanceClassMemory/12582880}
  • PostgreSQL: LEAST({DBInstanceClassMemory/9531392}, 5000)

マジでこういう値が入っている。

これを Parse し、Instance Class とその Memory size を取得して計算するというロジックを実装しないといけない。だるそう。

とはいえこれができると、現状の connection 数が max_con に達しそうだよ〜ってアラートが作れるので、役に立つ可能性は高いのでやる。

おしまい。

女性エンジニアのキャリアストーリーを集めた womeneng.jp 立ち上げと Netlify & hugo でハマったこと

背景

この記事を読んで

note.com

こう思い浮かんで

あおいさんとやるかーってなって

womeneng.jp 立ち上げました。

womeneng.jp

ちょっと前にこの業界の男女比であったり、男女でいうところ事実上女性がマイノリティであることであったり、そのマイノリティがゆえの不利益を何かしら被っていることであったりを考えた時期がありました。

~ Girls 系のイベントであったり、最近だと大平さん、菜穂子さん、ちょまどさんが Code Polaris を立ち上げたり、既に活躍されてる女性がこの問題の解決に向かって動いています。

chomado.com

note.com

この男女比の偏りは長期的に是正されるべきだと思います。しかしそのために、業界における圧倒的マジョリティ(情報系大学、大学院卒で、男性で、Software Engineer としてキャリアを重ねている)である自分個人に何ができるだろうとずっと考えていました。

その頃あおいさんに何かできることないですかね、って雑に相談してたことがあったりして。結局その時は何も浮かばなかったのですが、

wiroha さんの note が公開され、

ただなるべくハードルを取り除いて、自信とチャンスを与えられればもっと増えるかなぁと思ったりしています。

この考えに強く共感しました。

その頃、別の女性エンジニアの方から以下の TED の動画を教えてもらいました。

www.tedxtokyo.com

女性がエンジニアリングを職業にする割合が低いのは、その素養を養う、幼少期に与えられるおもちゃの段階で Gender 差が生まれている、それを解決するために自ら女性のためのおもちゃ会社を立ち上げた女性のエピソードでした。

wiroha さんのキャリアストーリーの共有も同様に"選択肢"を増やしてくれる取り組みだと思いました。

きっとこのムーブは続きそうだ、と思い、Static Web Site の Hosting ぐらいなら自分でもできる、と思い、あおいさんに相談して今回立ち上げに至りました。

あおいさんが寄稿してくれなかったら、やろうと言ってくれなかったら自分一人ではできなかったと思います。心から感謝します。

今後

womenengjp は GitHub の Open Repository です。Pull Request で Contribution できます。

github.com

今後は見つけ次第 Link を追加していくのをぼちぼちやろうと思っています。

また、現状は個人を特定できる形で、勇気ある方が書いてくれていますが、全員がそうではないと思っています。インタビュー形式のように、語り手の負担を下げる取り組みであったり、より匿名性が高い形でのエピソード掲載ができないか、という話をあおいさんとしています。

少しずつでいいのでキャリアストーリーの数が増え、将来、女性エンジニアになるかもしれないひとの選択肢を知る手段として役に立ち、"女性エンジニア"というくくりが必要ない世の中になればいいなと思います。

おわりに

ストーリー書いてもいいよ!とか、書いたよ!っていうひとは連絡くれたり、PR で追加いただけたり、このサイト自体を広めてくれると嬉しいです。

womeneng.jp

それでは以降は Netlify & hugo のハマりです。

ハマり

本当はもっと爆速で公開したかったのに5日間もかかってしまったのでハマったことををまとめます。

Netlify での HTTPS が有効にならない

Netlify では Netlify DNS を使っていると custom domain に対して Let's Encrypt の SSL 証明書をボタンポチるだけで準備してくれます。超便利。

が、これが24時間経っても DNS Preparation が終わらない。

サポートに問い合わせるも Community に聞いてくれと言われ、早く出したかったので Pro Plan にあげて 1on1 サポートをつけてもらった。

原因

CAA Record の設定が必要だった(?)(ただ、過去は同じドメインレジストリ、同じ Netlify の設定で、CAA Record なしでできたケースもあったので謎)

対処

以下の要領で CAA Record を Netlify DNS で作成

$ dig CAA womeneng.jp

; <<>> DiG 9.10.6 <<>> CAA womeneng.jp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7517
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;womeneng.jp.           IN  CAA

;; ANSWER SECTION:
womeneng.jp.        7166    IN  CAA 0 issue "letsencrypt.org"

;; Query time: 21 msec
;; SERVER: 2404:1a8:7f01:b::3#53(2404:1a8:7f01:b::3)
;; WHEN: Sun Jan 31 02:09:01 JST 2021
;; MSG SIZE  rcvd: 74

最初設定してたときはこの Issuer が間違っていた。

学んだこと

作業ログはこちら。

github.com

Preview Site で CSS が適用されない

Netlify では Pull Request を作成するごとに Preview Site が Deploy される。めちゃ便利である。が、なぜか PR 環境の場合 CSS が適用されない。

CSS を要求する url が以下のようにスラッシュが欠けていた。 js/bundle.js の前ね。

Got: Request URL: https://deploy-preview-2--naughty-mcnulty-91e54f.netlify.appjs/bundle.js Want: Request URL: https://deploy-preview-2--naughty-mcnulty-91e54f.netlify.app/js/bundle.js

Issue と PR はこれ。

github.com

github.com

.netlify.conf で build 時のコマンドを設定するわけだけど、DEPLOY_PRIME_URL がなんと preview site の場合は末尾のスラッシュを含まない。マジかよ。

docs.netlify.com

というわけで入れた。ugly な hack な気がするがしょうがない。これみんなハマらないのかな。

画像が Responsive にならない

Issue

github.com

スマホとか Window size が小さいものでみた時に画像が横幅 100% の resize されず横スクロールが必要みたいになっていてイケてない。

これはまぁもしかしたら hugo theme の upstream に contribution できることなのかもしれない。あとで Issue 起票してみよう。

css 知識 2 の知能でなんとかしました。

github.com

hugo template が custom css 使えて助かった。

2021-01-31 追記

template のほうに PR を投げて merge されました。良い話だ。

github.com

AWS RDS の Engine と Engine Version を Prometheus 形式で Export する OSS 作った

作った。

github.com

きっかけとしては、1月いっぱいに RDS の upgrade をしろというお達しが AWS からきていた件。

  • 廃止対象の PostgreSQL マイナーバージョン - 9.6.8, 9.6.9, 9.6.11, 9.6.12, 最低限必要な推奨バージョン - 9.6.16

  • 廃止対象の PostgreSQL マイナーバージョン - 10.4, 10.5, 10.6, 10.7, 最低限必要な推奨バージョン - 10.11

  • 廃止対象の PostgreSQL マイナーバージョン - 11.4, 最低限必要な推奨バージョン - 11.6

で、あわててあげたわけだが、結構前から通知がきていた。

このバージョンが Datadog にきていればバージョンによってはアラートをつけたりできなくもない?っていうのが発想。でもまぁ結局その AWS のお達しに気付けなければどれがヤバいか気付けないし、何バージョン離れてたところでやばいとか判断できない気もするが。。。まぁとりあえず送ってみることに。

こんな感じ。

f:id:take_she12:20210128155230p:plain

工夫した点

特にない。。。。。。。。。

go-aws-sdk は EKS の認証するツール書く時に書いたことがあった。

取得するのは以下3つ - Cluster Identifier - Engine - Engine Version

こんな感じになる。

aws_custom_rds_cluster_count{cluster_identifier="postgres-aya-production-a",engine="aurora-postgresql",engine_version="9.6.16"} 1
aws_custom_rds_cluster_count{cluster_identifier="postgres-aya-release-1595371533",engine="aurora-postgresql",engine_version="9.6.16"} 1
aws_custom_rds_cluster_count{cluster_identifier="postgres-aya-report-1611765597",engine="aurora-postgresql",engine_version="9.6.16"} 1
aws_custom_rds_cluster_count{cluster_identifier="postgres-rdev-02-a",engine="aurora-postgresql",engine_version="9.6.16"} 1
aws_custom_rds_cluster_count{cluster_identifier="recommendation-develop-a",engine="aurora-mysql",engine_version="5.7.12"} 1
aws_custom_rds_cluster_count{cluster_identifier="recommendation-edge-a",engine="aurora-mysql",engine_version="5.7.mysql_aurora.2.07.2"}

まぁ現状どのバージョンが残ってるかとかを探しやすくはなるし、どれぐらい残ってるかは見易くはなる気がする。

Deploy

いつものように Kubernetes Deployment として動かすが、AWS へのアクセスが必要。DescribeDBClusters を実行できる必要があるので。

で、IRSA 対応をはじめて手を動かしながらやってみている。

IAM Role 作って serviceaccount と紐づけて、deployment から serviceaccount を参照させる感じ。

おわりに

次回作は aws-ecr-image-scan-findings-prometheus-exporter の予定。ECR の image scan findings の結果を、Severity とかを送る。

木曜金曜はオフなので毎日新作リリースはおやすみ。土曜にでも出そうと思う。

GitHub の Issue の数を prometheus 形式で export する OSS 作った

作った。

github.com

github.com

これのお友達。

なぜ作ったか

Quipper では基本 Issue で仕事をしている。で、適当に Label も活用している。

もともとの Motivation は Open になってる Postmortem Issue が放置されてることだったりする。

結局いまだに放置されていてその問題は解決していないのだけれど....

f:id:take_she12:20210127054456p:plain

こんな風に metric として可視化されると、n 件たまったらアラートとかできる。するかはまだわからない。

そもそも今 Workload の管理というか、Issue 管理全然できてるとは言えない。が、まぁなんにせよ見えるようにして長期トレンドを見て何かアクションする、みたいなことはできる可能性がある。この手の可視化、metric 化はそれによって意味のあるアクションが取れるか、意味のある意思決定がとれるかは、とってみて眺めて味わう、というフェーズがないとなんとも言えんので、しばらくはちょっとでも「あると便利かも?」と思ったものはバンバン送ろうと思っている。

工夫した点

Label Filtering

Issue は多い。開きっぱなしのものも多い。しかも Quipper の場合は quipper/quipper にかなりの割合のメンバーが issue を作成しているので多い。3k とか 5k とかある。ので、取得時点で Label でフィルタリングできるようにしている。

github.com

GITHUB_LABEL という環境変数からとってきて、ListOption にいれる。

で、ないならないで良いようにもした。

github.com

Pagination

工夫というほどでもないけど。GitHub API は default で 30件、max 100件しか取れない。

ちゃんと Pagination 対応した。

github.com

ただ数k になると結構時間かかって、Ticker の Interval 以内に取得できないケースもある。

次回作

Github 編は終わり。次は AWS の RDS Engine Version を Prometheus 形式で Export するやつを作る。これまた役に立つか、Alert つけるにせよどのバージョンがアウトかを管理する必要があるので、そのへんどうできるかは不明だが、とりあえず作る。

GitHub の Repository の Pull Request の数を prometheus 形式で export する OSS 作った

昨日のこれ

blog.chaspy.me

自分の発表では prometheus 形式で export したら Datadog の Kubernetes Autodiscovery で datadog-agent が勝手に取ってくれて便利だよなんて言ったんですが

docs.datadoghq.com

prometheus 形式で export するのに個別にタグつけて export できないと思ってたんですが

godoc.org

In addition to the fundamental metric types Gauge, Counter, Summary, and Histogram, a very important part of the Prometheus data model is the partitioning of samples along dimensions called labels, which results in metric vectors. The fundamental types are GaugeVec, CounterVec, SummaryVec, and HistogramVec.

できる(できる)

ということを8億年前から知っていた @yuya-takeyama に教えてもらったので書き直しました。一応前のは残して別の repository に書きました。

github.com

つぎはぎだらけでだいぶ雑な気がしますがまぁ動いているからいいのだ。

これは何

prometheus 形式で Github の指定した repository の pull request の数を author, reviewer, label をタグとしてつけて export する君です。

f:id:take_she12:20210126035051p:plain

github.com

こっちは push のアプローチで、この中で Datadog に対して metrics を投げつけるんですが、

今回作った github-pr-prometheus-exporter は Datadog 関係ないです。prometheus 形式で、 8080:/metrics で metrics を export するだけ。

で、こういう annotation 書けば datadog-agent が取ってくれるので便利。pull 型のアプローチですね。使ってる manifest そのまま晒しちゃいます。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: github-pr-prometheus-exporter
  namespace: monitor
  labels:
    name: github-pr-prometheus-exporter
    owner: sre
spec:
  replicas: 1
  selector:
    matchLabels:
      app: github-pr-prometheus-exporter
  template:
    metadata:
      labels:
        app: github-pr-prometheus-exporter
      annotations:
        ad.datadoghq.com/github-pr-prometheus-exporter.check_names: |
          ["prometheus"]
        ad.datadoghq.com/github-pr-prometheus-exporter.init_configs: |
          [{}]
        ad.datadoghq.com/github-pr-prometheus-exporter.instances: |
          [
            {
              "prometheus_url": "http://%%host%%:8080/metrics",
              "namespace": "github-pr-prometheus-exporter",
              "metrics": ["*"]
            }
          ]
    spec:
      containers:
      - image: chaspy/github-pr-prometheus-exporter:v0.1.0
        name: github-pr-prometheus-exporter
        ports:
        - name: http
          containerPort: 8080
        livenessProbe:
          initialDelaySeconds: 1
          httpGet:
            path: /metrics
            port: 8080
        resources:
          limits:
            memory: 32Mi
          requests:
            cpu: 10m
            memory: 32Mi
        env:
          - name: GITHUB_TOKEN 
            valueFrom:   
              secretKeyRef:  
                name: "github-secret" 
                key: GITHUB_TOKEN
          - name: GITHUB_REPOSITORIES  
            value: "quipper/kubernetes-clusters,quipper/server-templates,quipper/monorepo,quipper/monorepo-global,quipper/qs-terraform,quipper/aya-terraform,quipper/iam,quipper/aya-iam,quipper/dns,quipper/aya-dns"
        securityContext:
          readOnlyRootFilesystem: true
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
      imagePullSecrets:
        - name: docker-hub
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: quipper/type
                operator: In
                values:
                - system-components

別に push 方式でも全然いいんですが、Datadog 関係の secret を持つ必要がないって点が利点ですかね。

前作と同じく環境変数 GITHUB_REPOSITORIES で対象リポジトリを指定します。

     - name: GITHUB_REPOSITORIES  
       value: "quipper/kubernetes-clusters,quipper/server-templates,quipper/monorepo,quipper/monorepo-global,quipper/qs-terraform,quipper/aya-terraform,quipper/iam,quipper/aya-iam,quipper/dns,quipper/aya-dns"

もはやこれを deployment として浮かせることすらしたくない(どっかのサーバレスな何かに image だけ指定していい感じに動いて欲しい)ぐらいには怠惰になってきた。

まぁ何はともあれ、push 形式の前作を cronjob で定期実行するよりはこっちのアプローチのほうがいいかなと思い書き直したという話でした。

次こそはこれの issue ver を作る。

GitHub の Repository の Pull Request の数を Datadog に送る OSS 作った

作った。

github.com

そういえば今日は July Tech Festa で、@songmu さんの OSS を細く長く続ける技術を聞いて、OSS 活動するぞ〜〜〜〜〜となって作った。

junkyard.song.mu

自分も Datadog に関する発表をして、custom metrics はいいぞという話をしたというのもあり、やるぞ〜〜〜〜となって作った。

これはなに

特定の Repository の Pull Request の数を Datadog に送る君です。

custom metrics の label には repository, author, label, reviewer がついてます。

f:id:take_she12:20210125035101p:plain

対象の Repository は環境変数で指定しています。

$ cat .envrc
export DATADOG_API_KEY="secret"
export DATADOG_APP_KEY="secret"
export GITHUB_TOKEN="secret"
export GITHUB_REPOSITORIES="quipper/kubernetes-clusters,quipper/server-templates"

どう使うのか

ちゃんと使えるかはまだわかんないんですが、PR 溜まりすぎたときにアラート発砲とかできると思います。あと個人的にも自分が Reviewer になってる PR が n個以上になったらアラートとかもできる気がします。まぁ別に Jasper で通知受けてるからそうそう貯まらないんですけども。

あと renovate が PR バンバン出してくるので、それも一定数たまったらみんなで見ましょうねみたいなムーブもできるかもしれません。

まだデプロイしてませんが、Kubernetes cronjob として Deploy して5分なり30分なりの間隔で定期実行させるつもりです。

何をしたのか

main logic に語るところはあんまりない。

まだ結構雑で、普通にチームメンバーにレビュー投げたらボロクソレビューが入るレベルだと思う。

GitHub から対象の Repository の PR 持ってきて、必要な情報だけ抜き出して(label, author, reviewer, number)それから datadog metric を作る材料をこねこねして custom metrics を送っているだけである。

github actions を使って goreleaser でリリースしたりタグ打ったら Docker push したり CI で lint 流すようにしたりしているがほぼ検索結果のコピペなのであんまり深く理解はしていない。actions 作られているの簡単に使えるので便利だな。近々 github-actions のこのモジュールっていうのかな。なんていうのかわからんが、も作ってみたい。

今後

Issue version も作ろうかなと思う。

思うところ

Datadog のタグの仕様がイケてない。

renovate の PR とか、renovate/datadogrenovate/datadog/2.6.11 って2つ label がついてるんだけど、datadog に同じ key の label を送ると renovate/datadog, renovate/datadog/2.6.11 とカンマ句切りのタグとなる。イケてない。やむなしか。Reviewer も複数人指定するとそうなっちゃんだよなあ。

おわりに

カンファレンスってさ、参加してなんかわかった気になるじゃん、でもそのあと行動しないと意味ないじゃん、で発表したし聴講して、ちゃんとアクションを起こしたので俺は勝ち。みんなも行動していこうな。JTF ラブ!

入社してから2年半

12/20 で2年半経った。

前回

blog.chaspy.me

なんかもうまた全然違うところまで来てしまった感があるし、はるか昔に感じるな。成長しているとも言う。

相変わらず挑戦と失敗をさせてくれる組織とマネージャーの @yuya-takeyama に感謝している。

振り返り

Platform Development の Lead

Application Platform, つまり Kubernetes のことだが、それの重要度は非常に高いし、SRE Team はこれをビジネス要求や開発者のため、もしくはサービスの信頼性のために適切に進化させていく必要がある。

特に詳しい @d-kuro に力を借りながら、Kubernetes 関連のことを話す Weekly Meeting をはじめて、Roadmap を引き、自分自身で今後の進化の重要な一歩と言える EKS への移行を実現しきった。

quipper.hatenablog.com

また、この延長でこのとき感じた課題を解決するために Cluster の Canary Switch も実現。総じてクラスタ切り替えはかなり楽になった。

quipper.hatenablog.com

この分野に強い知見を持つ @int128 が入社するまでには移行をやりきるぞ!という気持ちで、(実際は入社前には間に合わなかったけど)やりきった。影響範囲も大きく、技術的な不確実性も高かったプロジェクトだった。特に自分は kube-aws で管理していた自体の Kubernetes Cluster 切り替えを1度もやったことなかったので時間かかったり失敗したことも多くあったが、学習しながら完遂できたのはよかった。

Global Cluster の切り替えを行ったあと、Japan の分は @int128 にやってもらい、オンボーディングが終わったあとは彼にこの分野の Lead をおまかせした。

その後は System Component の GitOps 化、それに伴う renovate による component upgrade の簡易化、Nginx Ingress の部分導入など凄まじい進化を遂げている。

quipper.hatenablog.com

EKS は本当に"第一歩"だったんだなぁ、と終わってみてようやく思う。当時は kube-aws のサポートが追いつかず Kubernetes が EOL になってしまうから、と後ろ向きなモチベーションだったが、やはりやってみてわかることはたくさんあるね。

Infrastructure / Service Cost Management の Lead

あんまり大きな声では言えないが、Infrastructure / Service Cost に関してこれまであまり"ちゃんと"やれてなかった。

夏頃に @motobrew からこの Cost に関してヤバいのではと警笛をもらってから、できることから少しずつ実現している。

quipper.hatenablog.com

まだ道半ばで、適切な目標を持ち、分析をし、定量的に振り返る体制作りはこれからではあるが、Monthly で振り返り、着実に前に進めていると思う。

Global Development Team との関係強化

これはもう本当に悔しいし悲しいしつらいが、Global で大きい障害を起こしてしまった。何がつらいって「わかっていた」のに何もできなかったことだ。まぁそれは僕個人が悪いわけではないが、数日は落ち込んだ。

それをきっかけに、Global Developer との Meeting の機会がとても増えた。

また、それとは別に、当時は「やることが多すぎて優先度がつけられない」ということに悩んでいた。そこで彼ら彼女らが何が課題かを吸い上げるために、あるいは情報が流れてきやすくなるための関係構築のために、Global Developer との 1on1 を行った。

「定期試験」によるスパイクアクセスに対応するためにコンポーネントを開発し、Engineering で解決できたのも、そもそもお互いで会話して、関係性ができていたからこそだと思うので、ずいぶん前に進んだし、自分としても良い経験になった。そもそものきっかけが Business Owner の @naotori と話したことだったりもするので、コミュニケーションによって問題を解決できた。

quipper.hatenablog.com

ブログ記事化はしてないが、12月には Android Developer と一緒に Locust による Loadtest を実施した。望んだ結果が手に入ったわけでもないし、コミュニケーションの課題は依然残るものの、問題の質が変化したというか、前だったらお願いすらされなかっただろうし、頼ってもらえるようになっただけ進歩かなぁなんて呑気に考えている。

いずれにせよ着実に前には進んでいる実感はある。まだまだ道半ばなので継続して関係作りはしていきたい。

Team / Project Lead

まぁ上でいろいろ Lead したと書いてはいるんだが、5月に Lead Software Engineer のジョブタイトルがつき、Team / Project の Lead をしている。主にコミュニケーションのデザインやファシリテーションをしたり、Retrospective であがってきた Problem に対する Try を積極的に取ったりなんたりで貢献できていると思う。

次の半年

ちょっと今回は"意識"/"心意気"みたいなことを宣言してみる。

レバレッジの効く仕事をする

ちょっと抽象的ではあるが、やる仕事をしっかり見極めたい。というのも、本当にやること、やれることは無限にあるし、仕事の難易度もかなり難しくなってきている。Team や Project を Lead しながら Individual Contributor としても貢献し続けるためには、そのインパクトを最大化するためにどういった投資をするかという意識を常に持たないと、(自分が)疲弊したりチームに混乱を招きかねない。

本当にやるのか、なぜやるのか、どうやるのか、こういったことを今まで以上に見極めたい。

また、自分が得意としているコミュニケーションによる問題解決能力を特に存分に活かして、Japan / Global 両方の組織に貢献したい。

成果にこだわる

これはこれまでも意識をしていたことだけど、とにかく成果を出すこと。話はそれからだということ。1つ前のことにも関連するが、それで世界がどう変わったのか、ということを常に意識すること。かけた投資に対してインパクトを最大化すること。そのためにエンジニアリングの力を存分に活かすこと。これに今まで以上にこだわり続けたい。

クオリティにこだわる

自分に明確に足りてないことでいえば Software Engineering ... Programming による課題解決の部分である。お前それが仕事だろと毎年ずっと突っ込んでいるが、事実そうだから仕方がない。

やった仕事を「終わらせる」ことも大事だが、Delivery と Quarity を両立してこそ Professional だと思う。ちゃんとクオリティを出すことを目指したい。このあたりは模範的な同僚が多くいる幸せな環境なので、見習いながら食らいついていきたい。

Global Product Team に貢献する

引き続き SRE としては Global も担当範囲である。また、Global Product Development において Site Relaiblity の重要性は相対的にも増してきている。Site Reliability Engineering の実現のためにはコミュニケーション能力が必要不可欠である。引き続き関係性を構築するとともに、英語でガンガンコミュニケーションを取って、チームと、世界を変えていく。"世界の果てまで学びを届ける”ために、貢献できるポジションにいるのでしっかりやる。

ビジネスを理解し、エンジニアリングでビジネスに貢献する

成果にこだわることにも関係するが、それがどのようにビジネス価値を生むのかを常に考える。そしてそのためにはビジネスを理解する必要がある。もちろんコストも関係する。インフラコスト、ビジネスインパクトを考え、ビジネスを前に進められるエンジニアリングを行いたい。そのためにステークホルダーとのコミュニケーションは引き続きやっていきたい。

おわりに

^の心意気を実現するためには英語とか技術とかあれこれいるので、それについていけるようにやっていく。

おしまい。