taxin's notes

読書、勉強メモ etc.

UoPeopleでTransfer creditsを実施した時のメモ

概要

5月末に、UoPeopleでTransfer Creditsの申請が完了して48単位の単位移行が完了しました。
この記事では、Transfer Creditsの手続きをどのように進めたかをまとめていきます。
(単位移転は、EC1をpassしてdegree-seeking studentのStatusであることが前提となるので、気になる方はProgram Advisorに確認してみてください。)

www.uopeople.edu

また、申請時に下記のブログに大変お世話になったので、こちらも合わせてお読みいただけると理解度が深まるかと思います。

puchannel.livedoor.blog

medium.com

大まかな流れ

単位移転の大まかな流れは下記の通りです。
このブログでは、2番目のEvaluation reportの発行からまとめていきます。

  • (大学などでの)成績証明書の発行
  • UoPeople指定フォーマットのEvaluation reportの発行
  • Transfer Creditsの申請

Evaluation reportの発行

Transfer credit policyを見ると、Evaluation reportに関して下記のように記載されています。

https://www.uopeople.edu/wp-content/uploads/2020/07/Transfer-Credit-Policy-1.pdf

UoPeople will accept the transferred credits if the credits are from: A non-US accredited institution reviewed by an established foreign evaluation service, that is a member of NACES (http://www.naces.org/) or AICE (http://aice-eval.org/members/)


私はACEIでEvaluation reportを発行しました。
(名前が似ててややこしいですが、ACEI is a Charter and Endorsed Member of the Association of International Credential Evaluators (AICE)なので問題ありません。)

ACEI | About Academic Credentials Evaluation Institute

ACEIのevaluation-serviceのリンク (https://acei-global.org/evaluation-services/) から申請をした上で、下記の書類を郵送してレポートの発行申請を行いました。

  • 成績証明書 (英文で発行)
  • 卒業証明書 (英文で発行)

申請時には小学校から全ての学歴を列挙する必要があったり、郵送のオプションはデフォルトで付与されていないのでAdditional Feeを払ったりするので確認は必須です。
Reportの発行まで1ヶ月程度かかったような気がします。

Transfer Creditsの申請

ACEIからは下記のような封筒でEvaliation reportが届きます。

f:id:taxintt:20210529204753j:plain
img1

次に、UoPeopleのPortal経由で、Admissions > Transfer Creditsから単位移転の申請を行います。
届いたreportはプリンターなどでscanして画像ファイルに変換して、Portalからuploadします。

https://your.uopeople.edu/portal/TransferCredits/default

申請後にApproveされていることを同じページのリンクから確認して、単位移転は完了です。
f:id:taxintt:20210529205457p:plain

また、どの単位が卒業要件のどの項目に当てはまるかは記載はないので、Program Advisorに問い合わせて確認を行いました。
(メールで下記のような形でどの項目に紐づくか教えてもらいました。)

Business Strategy : --------- Elective
Corporate Finance : ----------Elective
Corporate Governance : -----Elective
Basic Seminar I/Basic Seminar II ------------ Elective
Health And Sports : --------------- Elective
International Economic Relations --  --------Social and Behavioural Sciences
...


また、UoPeopleのPortalでAcademic Achievements > Degree Audit Reportから、(移転した分も含めて) 詳細な単位の取得状況が確認できます。
単位移転後に、ここで単位の取得状況の詳細を確認しました。

https://your.uopeople.edu/portal/AcademicAchievements/default/DegreeAuditReport

f:id:taxintt:20210529205701p:plain
img2

終わりに

一連の申請にかれこれ半年以上かかってましたが、なんとか完了してほっとしています。
引き続きUoPeopleはやれる限り続けていきます。

参考リンク

www.uopeople.edu

2020年に買って良かったモノ

備忘録的に、2020年に買ってよかったものを雑にまとめてみました。
(二番煎じだけど気にしません)

ディスプレイ(BenQ GW2480T) + ディスプレイアーム(エルゴトロン LX モニターアーム)

今年に入ってから在宅勤務になったこともあって、デスク周りは一通り整備しました

座高が高いので、モニターアームで目線の位置にディスプレイの高さを調整できるのが嬉しい
画質的には特に不満は無いので、もう一枚ディスプレイを導入してMacクラムシェルモードで利用しようかと計画中です

www.amazon.co.jp

Amazon | エルゴトロン LX デスクマウント モニターアーム マットブラック 45-241-224 | エルゴトロン | モニタアーム&スタンド 通販

HHKB Professional HYBRID Type-S 日本語配列

Realforceのキーボードを持っていたので必要なかったのですが、完全に興味本位で購入

karabiner-elementsでのキー配置の調整など初期設定に手間取った記憶があるが、使い始めてからは快適だった
(キーボード自体は小さめなので、手の大きい人は使いづらいかもしれないと思いました)

Amazon | HHKB Professional HYBRID Type-S 日本語配列/墨 | HHKB | パソコン用キーボード 通販

CalDigit TS3 Plus

Mac用のハブとして、配線周りをまとめることができてデスクの見た目がスゴくすっきりしたので満足してる
(今年一番、買って満足度が高かったものかもしれない)


先述のディスプレイとかと合わせると、こんな感じのデスク周りになりました

Amazon | CalDigit TS3 Plus/Thunderbolt Station 3 Plus/Thunderbolt 3 ドッキングステーション(スペースグレイ・0.7mケーブル付き) | CalDigit | ドッキングステーション 通販

f:id:taxintt:20201231111226j:plain

Philips Hue

起床時・就寝時のタイマー機能には非常にお世話になっている
たまに家のNWが不調になるので、電気がつけられなくなったりして困ったりするが基本的には便利

Amazon | Philips Hue(ヒュー) | ホワイトグラデーション スターターセット | E26スマートLEDライト2個+ブリッジ1個+ディマースイッチ1個 |【Amazon Echo、Google Home、Apple HomeKit、LINEで音声コントロール】 | フィリップスライティング(Philips Lighting) | LED電球 通販

TRUST THOR LARGE TOTES

気付いたらキャンプ道具が増えていたので収納用のボックスとして購入
後述のハンマー・斧なども雑に荷物を入れても特に傷もついてないので、助かってます

Amazon|トラスト ソーラージトートウィズリッド TRUST THOR LARGE TOTES with LID [75L/オリーブドラブ]|収納ケース・ボックス オンライン通販

f:id:taxintt:20201231113714j:plain

UNIFLAME TSURUBAMI(燕三条乃斧)

薪割り用に購入
重量もそこまでなく、ソロキャンプなどにも持っていけるくらいにはコンパクトサイズで助かる

Amazon | ユニフレーム(UNIFLAME) TSURUBAMI 燕三条乃斧 684191 | ユニフレーム(UNIFLAME) | 鉈・アックス

MSR STAKE HAMMER

ペグ用のハンマーとして導入
こちらも持ち運びやすいコンパクトサイズで、登山用途でも流用できそう(というかそっちがメインの用途な気がする)

item.rakuten.co.jp

f:id:taxintt:20201231111010j:plain

インシデント対応を見据えた監視設計で考えたこと

はじめに

最近、本番環境のシステムの一部移行にあたって、Datadogを利用した監視設計と監視環境の整備を行う機会がありました。

その際の気付き・学びなど振り返りも兼ねて、久しぶりにこのブログを書いています。
特に今回は、アラート対応といった運用プロセスを他チームに移管したこともあり、インシデント対応に少しフォーカスした内容になっています。
(概念的な話がメインとなっており、内容自体はある程度一般化してまとめています。)

監視の基本

前提となる部分で押さえておきたい概念・考え方を記載しておきます。
基本的には「入門 監視」に書いてあることがベースになっています。
www.oreilly.co.jp

正常状態の把握

大前提として、CPU使用率など監視項目の観点で「正常に動いている」とはどういう状態かを定義する必要があります。
特定のAgentやサービスなど稼働を前提とするものがあれば、それも正常状態の定義時に考慮します。

  • CPU使用率:oo % 以下
  • 通常稼働しているサービス:xxx, xxx

特に、OS関連のメトリクス (ex. CPU usage) はそのままでは利用できないため、正常状態を表現できるように利用する必要があります。

CPU使用率の高騰とサービスが正常に動作しないことは相関がある可能性が高いですが、CPU使用率の高騰 = 正常に動いてない という単純な紐付けは禁物です。

MySQLが継続的にCPU全部を使っていたとしても、レスポンスタイムが許容範囲内に収まっていれば何も問題はありません。
これこそが、CPUやメモリ使用率などの低レベルなメトリクスではなく「動いているか」を基準にアラートを送ることが有益である理由です。
(入門 監視より)

例えば、CPU使用率がoo%を5分連続で超えた場合はサービスが正常ではない可能性が高いと定義して、アラート対応の中でサービスの稼働確認を行う形で利用しています。

OS関連のメトリクスをあえて利用している理由として、正常に稼働しなくなるという予測の観点でもアラートを飛ばすことができるためです。(正確な予測アラートであれば、事象発生前に対応の準備ができるというメリットがあります。)

アラート自体がサービスの稼働確認を行う外形監視も一つの選択肢としてあるかと思います。

継続的な改善

正常状態の把握を踏まえてアラートを設定する場合は、閾値の設定が重要なポイントになります。
oo%をxx分連続で超えた場合は正常ではないのでアラートを発砲する、と定義する際には計測した結果がベースとなります。

過去のインシデントや負荷試験の結果を基に、閾値を仮決めします。
その上で、計測 → 確認 → 閾値の修正 ... といった形で改善フローを回していくと、最終的には正常性を表現できている閾値の設定ができるようになるはずです。

全く同じアプローチで、SLI/SLOの定義と継続的な改善を行うことがベストプラクティスとして紹介されています。
blog.newrelic.co.jp

手順書(runbook)の整備

上記の方法でアラートを設定した上で、アラートに紐づける形で手順書(Runbook)を整備します。
特に、Runbookの整備では属人性を排除することを一番のポイントに挙げています。

より踏み込んだ内容に関しては、この後の部分でまとめます。

インシデント対応を見据えたポイント

次に、インシデント対応に焦点を当てた (Runbookの整備も踏まえた) 監視設計のポイントをまとめていきます。

インシデント対応の全体像

最初に、対応の全体像を把握しておきましょう。
オンコール対応に関する内容なのですが、全体像の把握も含めてPagerDutyのドキュメントが参考になります。
response.pagerduty.com

必要な要素をざっくりまとめると下記の通りです。

  • Prepare: アラート設定や対応に必要な権限・環境の整備 etc.
  • Triage: 問題の緊急性の判断
  • Fix: 事象に対する原因調査・対応
  • Improve: 事象の根本解決を想定した対応、ポストモーテムの作成
  • Support: オンコールのスケジュール調整、オンコール当番間での引継ぎ

この全体像を踏まえて、インシデント対応を見据えた考慮点をまとめていきます。

アラートの発砲に対する意味づけ

(アラートの重要度の定義にもよりますが) アラートの発砲自体をTriageの第一歩と見なすこともできると考えました。

つまり、アラートによって事象の重大度を表現できるのであれば、それを基に対応フローや別チームのメンバーへのエスカレーションといった後続のプロセスにつなげることができます。
単に事象発生の可能性があるので準備するだけでいいのか、実際に事象が発生しているので早急な対応が必要なのか etc. はアラートそのもので判断できるべきです。
(最近読んだ、Datadogのe-bookにも同じようなことが書かれていました。)

www.datadoghq.com

ここで気をつけたこととしては、アラートで扱う事象のscopeを極端に大きくしないことです。
先ほど記載したような、事象対応への準備や対応といった部分も一つのアラートで扱うのではなく、分けて扱うべきと考えました。

Datadogでは、テンプレート変数を利用して単一のアラート (Monitors) の中で条件分岐をさせて、通知するメッセージと重要度をパターン分岐させることができます。
そのため、管理単位 (Monitors) としては単一ですが、アラートとしては複数種類 (ex. Alert, Warning)のアラートを発砲することができます。

docs.datadoghq.com

単一のMonitorsの定義の中でAlert, Warningの発砲を行う際の閾値を設定します。
Datadogのテンプレート記法の話になりますが、下記のようにAlert, WarnのセクションごとにSlackでの通知時のメンション(@sreteam)と通知先チャネル(@slack-hogehoge-alert-emer)を指定できます。

// alert
{{#is_alert}}

...

{{!-- \@sreteam --}}<!subteam^hogehoge>
@slack-hogehoge-alert-emer 
{{/is_alert}}

{{#is_alert_recovery}}

...

{{!-- \@sreteam --}}<!subteam^hogehoge>
@slack-hogehoge-alert-emer 
{{/is_alert_recovery}}

// warning
{{#is_warning}}

...

{{!-- \@sreteam --}}<!subteam^hogehoge>
@slack-hogehoge-alert-warn 
{{/is_warning}}

{{#is_warning_recovery}}

...

{{!-- \@sreteam --}}<!subteam^hogehoge>
@slack-hogehoge-alert-warn 
{{/is_warning_recovery}}

上記の観点でアラートを整理することによって、アラートに紐づくRunbookに関して手順内の複雑性を最小限にすることができます。

コンテキスト (スイッチ) に対する理解

先ほど、Runbookの書き方について触れましたが、Runbook内のパターン分岐に関しても留意しながら手順を整理していました。

特に、緊急対応が必要な時のパターン分岐・その場での判断は非常にリスクが高く、対応する側としても非常にストレスフルな状態になります。

パターンの漏れが無いように単一のアラートで十数種類の対応パターンを用意しても、対応時に適切な判断ができるかは難しいと思います。
なるべく分岐回数は少なくして、上から手順を流して処理できればベストと感じました。

Slack channelについても同様で、通知されるchannelに関してもコンテキスト (どのような意味合いで利用されているか) を確認して利用する必要があります。

このchannelは全てのメッセージをwatchする、これはちゃんと見なくてもいい etc. のようなchannelごとの暗黙的なコンテキストスイッチが存在する可能性があることに留意しましょう。
(自分の場合は、アラートの種別と通知先について移管先のチームに共有した上で認識齟齬が無いかを確認していました。)

終わりに

以上、インシデント対応を見据えた監視設計で考えたことについてまとめました。

監視設計に関しては、メトリクスの扱いからアラートの中身まで考えることが多く、奥深いなと実感しています。
サービスの安定稼働を裏で支えられる監視設計ができるように日々勉強していきます。

Cloud runでSlack botを作成した時にハマったこと

はじめに

GCPのCloud runを利用してSlack botを作成した際にハマったことを備忘録として残しておきます。

Slack Bot作成時には下記のようなResourceも利用しています。

  • Cloud Scheduler: Cloud runのServiceを起動する
  • BigQuery: Cloud runからクエリを実行してTableからデータを取得する

Cloud run起動時のService Account

最小限の権限でCloud runを起動する場合には、Service Accountを新規作成して必要なRoleを紐付けます。
その状態で--service-accountのオプションで作成したService Accountを指定してCloud runを起動します。

cloud.google.com


Cloud run→BigQuery(Table)に対してクエリを投げるようなSlack bot(Cloud runのService)には、下記の権限が必要になります。
(SAに紐付けられた権限を用いて、Cloud run上のプログラムでBigQueryジョブを実行してTableを参照するため下記のようになります。)

  • bigquery.jobs.create
  • bigquery.tables.getData
  • iam.serviceAccounts.actAs

cloud.google.com

cloud.google.com


上記の権限を利用するために、Service Accountに対して下記のRoleを紐付けます。

  • roles/bigquery.jobUser
  • roles/bigquery.dataViewer
  • roles/iam.serviceAccountUser

cloud.google.com


(+α)別ProjectのBigQuery(Table)にクエリを投げる

Cloud runが起動しているProject(A)から別Project(B)のBigQuery(Table)にクエリを投げるケースがあります。
先述のBigQuery関連のRoleは、下記のGCP ProjectのIAM RoleをService Accountに紐づけます。

  • roles/bigquery.jobUser → Project(A)
  • roles/bigquery.dataViewer → Project(B)

これは、BigQueryのジョブをCloud run上から実行することから、roles/bigquery.jobUserの権限はCloud runが属しているProject(A)側にアタッチする必要があるためです。

REST API ライブラリまたはクライアント ライブラリを使用して
プログラムで BigQuery ジョブを実行するには、次のようにします。

  1. クライアント コードによって生成された一意のジョブ ID を使用して、jobs.insert メソッドを呼び出す
  2. 定期的にジョブリソースをリクエストし、ステータス プロパティを調べて、ジョブの完了を確認する
  3. ジョブが正常に終了したかどうかを確認します

cloud.google.com


Cloud Scheduler用のService Account

Cloud Scheduler→Cloud runでServiceを起動する際には、Cloud Scheduler用のService AccountにCloud Run Invokerを付与する必要があります。
(手順的には下記のドキュメントが参考になります。)

cloud.google.com

また、注意点として先述のService Accountとは別にCloud Scheduler Service AgentのRoleが付与されたService Account (service-[project-number]@gcp-sa-cloudscheduler.iam.gserviceaccount.com) が必要になります。

本来は、Cloud Scheduler API を有効にする際に自動的にService Accountが作成されます。
ただし、2019年3月19日より前にこの API を有効にしていた場合は、この役割を手動で追加する必要があります。

cloud.google.com


リージョンを跨ぐ状態でのCloud Scheduler → Cloud runの起動

通常の状態では、(同一のGCP Projectであっても) リージョンを跨ぐ状態でのCloud Scheduler → Cloud runを起動することはできません。

これは、Cloud Scheduler, Cloud runが両方ともRegionに紐づくリソースで、Cloud SchedulerからのRequestはGCPのNetwork(VPC?)を利用するため、VPC周りの設定次第では到達しないためと考えられます。 (明示的に公式ドキュメントに記載してある部分は見つけることができませんでしたが、ahmetb/cloud-run-faqに記載がありました。)

If any other private service (e.g. GCE VMs, GKE) needs to call 
your Cloud Run application, they need to use this public hostname.

However, despite you’re making requests to public IP from a GCE VM 
in the same region (or possibly on cross-region if you're on GCP Premium network tier), 
the traffic won’t leave Google’s own network.

github.com

未検証ではありますが、Serverless VPC Access Connectorを利用することでこの部分は解決できるかもしれません。 cloud.google.com

終わりに

Cloud run自体は簡単に利用できますが、他サービスとの連携面などで注意する点があります。
このBlog記事がCloud runを利用する方の助けになれば幸いです。

転職して一ヶ月経った

tl; dr

色々やっています。
Kubernetesは引き続き細々とやっていきます。
コード書く機会を増やしていきたい。

何やってるの?

8月に転職して某社でSREとして働いています。
転職の経緯などはこちらに記載しているので、よろしければどうぞ。

taxintt.hatenablog.com

今はDatadog使って監視周りの改善活動をしたり、SLI/SLOの導入のためにDesign Docsをベースにチーム用のガイドラインを書いたりしてます。
Monitoring, Logging, Alertingの改善やインフラ更改のお手伝いなど、やることはたくさんありますが楽しく過ごしています。

コードはほとんど書いていません。(もとからそんなに書いてなかったので書く量としてはそんなに変わっていないです。)
Cloud Functionsを触った時に少しGoを書いたり、Pythonを書いたりしたくらいです。

最近やったこと

8月末にCKAを取りました。(Score: 86%)
内容が9月から変わるとのことで、勉強内容自体はあまり参考にならないかもしれないので単体で記事にするのはやめました。

training.linuxfoundation.org

試験対策として、Hard wayを復習したりUdemyのCKAのコースを一通りやったりしました。
Udemyのコースは、Static PodやKubernetes NetworkingのベースとなっているNetwork Namespaceなどが初見の内容も多く、まだまだ知らないことがあるなあ...となった記憶があります。

www.udemy.com

これからやりたいこと

CKAの勉強もひと段落したので、9月以降は隙間時間でコードを書いてきたいと考えています。

理由としては2つあって、一つは技術的な課題に対してコードを書いて簡単なツールが作っていれば「痒いところに手が届く」ケースが増えたこと、もう一つはスキル的に伸び悩みを感じている今の状態から脱却するための足掛かりにしたいという理由です。

ゴリラさんの「プログラミング上達のコツ」をたまたま拝見したり、参加するMeetupの中でインフラエンジニアがコードを書くことに関する話が出てたりする中で、今年の残りはコーディングに力を入れようと思いました。
docs.google.com

インフラに関連する部分で小さなツールをGoで作り始めるところから始めていきたいです。
(なんとなくアイデアはあるので、それを形にするところから...)

最後に

何とか生き残れるように頑張りますので、これからもよろしくお願いします。

退職エントリ

TL; DR

2020年の7月末をもって、3年と4ヶ月勤めたSIerを退職しました。

誰?

@taxin_tt という名前でTwitterやったり、blog書いたりしています。
k8s初心者向けのMeetupであるKubernetes Meetup Noviceの運営もやっています。(運営メンバー募集中ですので興味あればお声がけ下さい。)

github.com

speakerdeck.com

自身の振り返りも兼ねて、この記事を書いています。

どんなことしてた?

退職する直前までは、AWSのインフラ運用とコンテナ環境で利用するセキュリティツールの機能検証を行っていました。
AWSとセキュリティ(コンテナ + 認証・認可) に比重を置いて仕事をしてきたと思います。

それ以前は、色々な仕事・勉強会に携わらせていただきました。

  • コンテナ環境におけるセキュリティに関する勉強会 + 社内セミナーの講師
  • 自社サービスを用いた業務フロー改善のPoC
  • 自社製品の導入サポート etc.


なぜ退職したの?

一言で言うと、自分が取り組みたいことと会社内で求められることの間にギャップがあり、それを埋めていくことが難しいと判断したからです。

取り組みたい技術分野への(案件)アサインや業務における技術的な部分とマネージメントの比率などいくつかギャップを感じる部分があり、最終的に社外で自身の希望を満たす仕事を求めることにしました。

会社自体にネガティブな印象を持つかもしれませんが、尊敬できる人も多く、(少なくとも自分の観測範囲では)非常に良い環境だと思っています。


どんなことやるの?

とある会社のSREチームに入ります。(具体的に何をやってるかはいずれまとめる予定です。)
前職ではチームの作業区分の影響でインフラの一部のみ見てきましたが、新しいところでは一通り全て見ることになりそうです。

DB, キャッシュ周りは個人的にちゃんと勉強したいです。(というか何も知らないので基礎知識は身に付けたい)


その他

その他と言いつつ、書いてみたらこっちの方が分量が多くなってしまいました。

特に記事にしてはいなかったのですが、4月からUoPeopleのComputer Scienceコースに入学していました。
継続して学習を続けることができればCSの学士号(Bachlor)を取得することができます。

www.uopeople.edu

文系出身ということもあり、Computer Scienceの基礎知識が足りないことに対する不安を常に持っていました。
自学自習でカバーすることも考えたのですが、体系的なCS分野の学習+英語学習の両方ができると考え最終的にApplyすることを決めました。
(下記の記事などを参考に、最終的には「やってみて違ったら別の方法に切り替えればいいでしょ」くらいの気持ちで決めた気がします。)

tmkk.hatenablog.com

snamiki1212.com

転職活動との掛け持ちに関してですが、正直その時は掛け持ちできませんでした。
4月下旬~5月下旬は転職活動もピークになり、加えて仕事とプライベートの問題に挟まれて折り合いがつかなくなり、最終的にAdvisorと相談してCourseをDropしてお休みしていました。
(TwitterでUoPeopleの課題のこと呟かなくなったな、こいつ...」と思われた方もいるかもしれません。)

次のTerm1 (First dayは9/3) からCourseは再開するつもりです。
その頃には仕事の要領も掴んで、業務とCourseを両立できるようになっているでしょう。(多分)

www.uopeople.edu

これからも学習は続けていきたいと思います。

最後に

KubernetesのWorkspaceに流れてきたSlackメッセージに反応してなければ、社外の人と関わりを持つこともなく、自身のキャリアについて考えてこの年次での退職を決断することもなかったと思います。
(今振り返ると、この集まりに参加して本当によかったなと実感しています。)

f:id:taxintt:20200527000533p:plain

こんな感じで、チャンスがあれば手を出してみる(動いてみる)ことを意識して引き続きやっていきます。
皆様、これからもよろしくお願いします。

個人目標の振り返り(2020年上半期)

はじめに

7月も半月近く経過してしまったので、今年の上半期振り返り記事を書いてみようと思います。
仕事関連のものは含めず、個人的に実施したものを中心に「何をやろうと計画して」「どこまでやったか」を振り返りました


上半期の目標と振り返り

上半期は、やりたいこと・興味のあることをいくつかの分野に分けて目標設定を行いました。
分野はざっくりと下記のように分けました。(AWSなど仕事で触っているものは下記の分野からは外しています。)

  • インフラ周りの基礎 (OS, NW etc.)
  • コンテナ / Kubernetes
  • IaC (主にTerraform)
  • アウトプット
  • コーディング
  • Private

目標をDaily or Weekly or Monthlyのタスクに落とし込んだものに関しては、目標の左側に設定したタスクの実行頻度を記載しています。
一部、1月〜3月で実施したものもありますが、4月〜6月で実施した内容がメインとなります。


インフラ周りの基礎 (OS, NW etc.)

インフラ基礎の学習: 1.5冊 / 3冊 (Not Yet)

4月〜6月までで、下記の3冊を課題図書としました。
一番上の本のみ読み終えて、2つ目の「ITインフラの仕組み」については現在も読み進めています。

www.amazon.co.jp

www.amazon.co.jp

www.amazon.co.jp

上半期を振り返って、最も改善が必要な部分は「本・Blog記事をベースとしたインプット」だと考えています。
アウトプットをメインに据えた目標設定をしていたこともありますが、それを差し引いても上半期のインプットの量は想定より少なかったです。

原因に関しては、ざっと下記のようなことが挙げられるかと思います。

  1. 技術書を読み進めるスピードが単純に遅い
  2. (本の内容が) 単なる文字列としてしか頭に入ってこない現象が度々あった
  3. インプットした本の内容とそれをベースにした考察・検証を「どこにどのように」まとめるかが決めていない

2.に関しては、単なる集中力の問題かなとも思いつつ、解決策が見つからなくてもやもやしていたのですが、リーディングトラッカーの存在を最近知ったので下半期はこれを利用してみます。


(1.に関しては、2の現象によって読み進めるのを止めたりした部分もあるので、リーディングトラッカーでどの程度改善できているかを見ていきたいと思います。)

また、3.に関しては、Hackmdにまとめつつ、はてなBlogに小さめの粒度で内容をまとめようかなと計画しています。
(負担にならない程度の小さめのアウトプットによって記録を残し、インプットによる知識を定着させることができればベストです。)

コンテナ / Kubernetes

Kubernetes The Hard Wayの完走 + Blog記事作成 (Done)

Kubernetes The Hard Wayを完走し、全Chapterの解説記事を作成しました。
(下記のChapter1の記事からChapter13までの解説記事をBlogに書きました)
taxintt.hatenablog.com

自分が運営として携わっているKubernetes Meetup Noviceの運営メンバーで集まって1日かけて実施しました。
また、完走後に勉強した内容を記事でまとめる宣言もしていたので、最後のChapterまで記事を書き切れてよかったです


Kubernetes完全ガイド読了 + 各リソースの検証: 5P / 日 (Not Yet)

当初はCKAを7月前半に受験する想定で、上記の学習を実施してました。
6月中は継続的に時間を取ることが難しかったことから、CKAの受験時期をずらしたので学習も一時的に中断していました。
(中断前までで7割程度読み終えていて、現在は学習再開しています。)

完全ガイドを読み終わったら、試験対策としてUdemyと下記の問題集を一周する予定です。
www.udemy.com

github.com

(バウチャーの有効期限もあるので)CKAの試験内容は変わるより前の8月の初旬~中旬にCKAを受験する予定です。


余談ですが、Kubernetes完全ガイドの第二版が発売されることを知りました。
(第一版を読了する前に第二版が発売されることのないように、早めに読み進めなければ...)

books.rakuten.co.jp


CI/CD Pipelineの「プロトタイプ」作成 (Done)

Kubernetes環境を前提としたCI/CD Pipelineに興味があったので自分で作ってみました。
GCRへのイメージプッシュからGKEへのデプロイまでの基本機能をCircleCIとKustomizeを用いて実装しました。
taxintt.hatenablog.com

基本的な機能の実装にとどまっているので、このプロトタイプをベースに修正・追加の実装を行っていく予定です。

IaC (主にTerraform)

Pragmatic Terraform on AWSの写経: ? P/日 (Done)

上記は、1月〜3月で実施したタスクの内の一つです。
(何ページずつ進めていたかは失念しましたが、4,5P/日くらいで進めていた記憶があります。)

booth.pm


一通り、写経してみてTerraform(HCLの書き方も含めて)に慣れたのは大きいと思います。
実際の業務では、単純に書くだけではなくディレクトリ構成・環境差分への対応方法・tfstateの分割など実運用を意識した設計や実装をする必要があると思うので、そういった観点での学習もできればいいかなと思います。


アウトプット

Blog記事の執筆: 記事2~3本 / 月 (Done)

上半期だけで、20本 (振り返り記事も含めて)の記事を作成していました。
どのような記事を書いたかに関しては割愛しますが、コンテナ・Kubernetes関連の記事が7割くらいを占めていたと思います。

(20記事程度書いて、450アクセスいかないくらいでした。)
f:id:taxintt:20200715212938p:plain


(社内/社外の両方で) 勉強会・Meetupでの登壇

上半期は人前で話す機会に恵まれました。
社内向けには、NIST SP800-190をベースにしたコンテナセキュリティの概論についてセミナーをしました。 (社内向けのセミナーなので、スライドは非公開です。ご了承ください。)

社外向けには、Kubernetes Novice Tokyo(#1)で、EKS 101というタイトルでLTをしました。
speakerdeck.com


コーディング

コーディングに関しては、春頃から時間を確保して色々やっていました。
(AtCoderに関してもやっていましたが、他のタスクを優先して現在は気が向いたらABCに参加するくらいです。)

N予備校(プログラミング入門 Webアプリコース) : 2レッスン/日 (Done)

アプリケーションの実装における基礎を一通り頭に入れるために上記のコースをやりました。
単にコードを書くだけではなく、API設計やデータモデリングの部分も説明されていたので、設計面を踏まえた上で実装のレッスンに移れるという点で非常にありがたかったです。
www.nnn.ed.nico

VMベースでの環境構築に耐えかねてDockerを用いてPostgreSQLのDB環境構築を行った際には、その内容もブログ記事として書いたりしました。
taxintt.hatenablog.com

Learn-go-with-tests : 1レッスン/日 (Not Yet)

現在は、Goの学習のために、TDDをベースとしたこのテキストを使ってコードを書いています。
andmorefine.gitbook.io

もともと、Pythonをメインで書いていて動的型付け言語しかまともに書けない状態だったので、静的型付け言語で且つとっつきやすそうなGo言語を勉強しています。
(KubernetesとGoの相性が良いこともあり、何かしら応用できるのではないかという部分もモチベーションの一つになっています。)


Private

ランニング: 1回 / 週 (Done?)

上記に関しては、大体目標達成することができました。
(厳密に言うと1,2月は一回ずつ足りないかもしれません)

  • 1月: 19.88km / 4 Runs
  • 2月: 33.97km / 4 Runs
  • 3月: 35.26km / 5 Runs
  • 4月: 52.20km / 8 Runs
  • 5月: 52.85km / 7 Runs
  • 6月: 58.35km / 9 Runs
  • 上半期Total: 252.52km / 37 Runs

雨と引越しなどでバタバタしていたこともあり、最近は家の周りをウォーキングするにとどまっています。
(前回のRunから2週間近くも間が空いてしまっています。早く梅雨が空けて欲しい...)


英会話: 2回 / 週 (Not Yet)

コロナの影響で校舎が閉鎖してしまったこともあり、目標は未達成となってしまいました。
(対面式のスクールに通っているので、ここはどうしようもない部分ではありますが...)

英語で話す機会を増やしたことで、英語を話す際は多少は口が慣れてきました。
その一方で、会話時に語彙・文法の貧弱さが出ているので、下半期はこの部分のインプットが必須になってくると思います。


下半期の目標

下半期に関しては全体的にインプットの比率を高めて、同時にインプットの質の改善にも取り組んでいきます。
目標設定と日々のタスクへの落とし込みは実施中なのですが、現段階で下記は実施予定です。
(下半期の目標設定の話はまた別記事で書こうと思います。)

インプット(分野全般)


コンテナ / Kubernetes

  • CKA / CKADの取得
  • TerraformでのGKEハンズオンの作成


アウトプット

  • 1, 2記事 / 月の頻度でのブログ記事の作成


コーディング

  • (Golang) client-goを用いたサンプルクライアント or TUIツールの実装