Ya8 2024
fujiwara-ware OSSをひたすら紹介する
作ったけどブログすら書いてないやつもある
社内事情を切り離す
Terraform派
Go
互換性が高い
シングルバイナリ
JSのランタイムが公開されていない
ECSのデプロイ
アプリケーションのデプロイはライフサイクルが異なる
抽象度が高い
SAMやServerlessはやることが多い
ecspressoの機能をいくつか独立させた
タスクのライフサイクルをいろんなログから収集して時系列順にする
Lambdaのエントリポイントにできる
Lambda Function URLなどをGoのnet/httpで書ける
Lambda関数と同じコードをCLIで動かせる
環境変数を扱えるflag parser
tfstateを取得してparseして中身を見る
ecspressoの設定ファイルにリソースのIDをハードコードしたくない
terraformに依存していない
interactive mode
ALBのOIDC認証機能のJWTを検証する
実はJWTではない
nginxのauth_requestと組み合わせられる
ECRを安全に掃除する
ライフサイクルルールは危険
ecrm plan
RI
リポジトリの使い分け
個人だと勢い重視でいける
会社のリポジトリを作るには申請が必要
SREのキャリア、 あるいは生態
SREは役割ではなく文化
SREの活動は見えにくい
誤解
サーバーを飼っていなかった
成長
最初は成果を出せなかった
チーム付きSRE
周りに詳しい人がいなくなった
一人でもやっていけるように
自動化
スキル向上
伝える
「どうやったら短期間で最強のSREになるか」
開発合宿
仕事の進め方がわかった
崖から突き落とすモデル
立場が人を作る
計画的偶発性理論
メンバーを成長させるには?
SREの楽しさ
システムだけではない改善
信頼性のコントロール
障害対応の楽しみ
モチベーション維持
今やるべきことをよく考える
広く浅くでもいい
深く潜れるようにはする
自分ごと化
「専門家はいない。私たちしかいないんだ。」
成長すると仕事を任せられる
ヒロイズム
SREingの文脈では、障害対応などが特定の人に偏ること
成長機会を奪う
感度の低下
バーンアウト
スケールするか
社内で自分のことをSREと呼ばない
固定観念を持たせない
インフラエンジニアの転換?
開発と運用の分断を避ける
「越境」という単語がわざわざ出てこない世界に
相互理解
崖から突き落として成長してもらうには素質が要るのではないか
RADIUS
UDP
Authentication
Authorization
Accounting
プロキシができる
元々はダイヤルアップ接続
Remote Access Dial In User Service
RADIUSレベルで再送
RADIUSレベルで暗号化
共有鍵
EAPのほうがいい
IPSec
md5を過信したプロトコル
PAP
user:passをそのまま流す
CHAP
challenge and response
MS-CHAP
EAP
なんでもあり
RADIUSとRADIUS Accountingは厳密には別
中身は同じ
標準のlistenポート番号は違う
共有鍵とパスワードが特定されるリスクがある
中間プロキシがパスワードの隠蔽をいったん解く
輻輳制御がない
がんばる
FreeRADIUS
デファクト
RFCの地図を作る
GPLv3にしたくないとき
リバースエンジニアリング
Diameter
RADIUSの後継
携帯電話通信ではゴリゴリ現役
RFCにテストスイートがある場合がある