SudoWorks

Cloud Infrastructure Engineer Portfolio

Cloud Infrastructure Engineer

信頼性を、設計と検証で支える。

AWS・IaC・可観測性・運用改善を軸に、
障害時にも正しく振る舞うシステムを設計・実装しています。

Focus

  • 01 Reliability / SRE
  • 02 AWS / Cloud Infrastructure
  • 03 IaC / Platform Engineering
  • 04 Observability
  • 05 Automation / Developer Experience
  • 06 AI-assisted Engineering
Primary case / NOC-AI

01 / Selected Work

信頼性の境界を、
実装で示す。

正常系の機能だけでなく、障害時の権限・状態・復旧・検証までを設計対象にしています。NOC-AIを中心に、異なる三つの境界での実装を示します。

Selected Work 01

Operations Control Plane

AI-assisted Operations Reliability

NOC-AI

AIの判断だけに運用操作を任せず、承認・状態・実行・Reconciliation・Verificationを分離した運用制御基盤。

7日間継続稼働検証：実施中

Control path

  1. 01Approve操作意図を承認
  2. 02Persist状態を永続化
  3. 03ExecuteWorkerが実行
  4. 04Reconcile不確実な結果を収束
  5. 05Verify独立して結果を検証
Engineering evidence6項目の検証と限界を確認

Engineering evidence

障害時のふるまいを、状態遷移として検証。

完了したfailure validationだけを検証済みとして扱い、進行中のsoakと分けて表示しています。

Durable state
PostgreSQL job / leaseにcontrol-plane stateを保持。
Crash recovery
Worker crash後の処理回復をfailure injectionで検証。
Ownership
lease競合時のstale-owner rejectionを検証。
Uncertain write
結果が不確実なwriteをReconciliationで収束。
Verification
実行経路から独立した結果確認を実施。
Evidence boundary
商用本番利用および一般的なexactly-onceは主張しません。

Selected Work 02

Asynchronous Delivery

Hooklane

受け付けた非同期処理が配信を完了するまでの障害境界を扱います。retryとrecoveryを例外ではなく、基本動作として設計します。

Focus
非同期配信 / retry / recovery
Behavior
受け付け後の中断を前提に、retryとrecoveryを通常経路として扱います。

Selected Work 03

Product Reliability

Office Hours

並行リクエストで同じslotを二重取得させず、retryを安全に扱う、動作する技術対話リクエスト機能です。

Focus
Idempotency / concurrency protection / privacy-conscious storage
Platform
AWS CDK / container runtime / observability
Boundary
CDK synthまで検証済み。AWS deployと自動通知は未実施。
受付フォームへ

02 / Capabilities

扱う領域。

インフラ構築そのものではなく、サービスが継続して正しく動くための設計・実装・運用を一つの系として扱います。

  1. 01

    Reliability / SRE

    障害モード、復旧経路、運用可能性を先に定義。

  2. 02

    AWS / Cloud Infrastructure

    実行環境と依存関係を、運用境界まで含めて設計。

  3. 03

    IaC / Platform Engineering

    再現可能な構成と安全な標準経路をコードで提供。

  4. 04

    Observability

    状態を推測せず、判断に必要なsignalとして可視化。

  5. 05

    Automation / Developer Experience

    反復作業を減らし、失敗時にも回復できるworkflowへ。

  6. 06

    AI-assisted Engineering

    AIの提案と実システムへの操作権限を明確に分離。

03 / Engineering Evidence

雰囲気ではなく、
実測で語る。

表示中の値は、このページを配信するOffice Hoursプロセスの実測です。NOC-AIのfailure validationとは明確に分けています。

Evidence source

Office Hours / current process

カウンターはプロセス再起動ごとにリセットされます。

Readinessを確認中…ローカルRuntime
処理したリクエスト
—
保存したリクエスト
—
拒否した競合
—
プロセス稼働時間
—

Write guarantee

DBが所有権を調停

ローカルではunique constraint、AWS設計ではconditional transactional writeがslotの所有者を決めます。

src/local/sqlite-booking-repository.ts

Failure contract

扱えるエラーへ変換

validation、競合、rate limit、依存先障害、unexpected errorを一貫したcodeとHTTP statusで返します。

src/http/api.ts

Operability

LivenessとReadinessを分離

プロセスの応答と、設定された永続化先がtrafficを受けられる状態を別々に確認します。

docs/operations/runbook.md

Evidence boundary

クラウド設計は未適用

CDK synthとassertionで設計意図を検証。deployの記録はないため、AWSにdeploy済みとは主張しません。

infra/office-hours-stack.ts

04 / Engineering Principle

障害時のふるまいを、
先に設計する。

Reliabilityは後から足す監視項目ではなく、権限・状態・回復・検証の境界を明示する設計上の性質だと考えています。

  1. 01

    権限を限定する

    提案・承認・実行の責任を分け、操作できる主体と範囲を明確にします。

  2. 02

    状態を永続化する

    プロセスの寿命に依存せず、retryとrecoveryが判断できる状態を残します。

  3. 03

    結果を独立に確かめる

    実行の成功応答だけを信頼せず、外部状態をReconciliationとVerificationで確認します。

05 / Supporting Work

周辺の実装と検証。

主要事例を補う小さな実践です。公開できるEvidenceの範囲を越える成果や運用実績は主張しません。

01

FairGate

Reliabilityを支えるシステム。詳細は今回の公開Evidenceの範囲外です。

02

Repo Health Doctor

リポジトリ健全性を確認するための実装。

03

Ops Signal Lab

運用signalを扱う検証。規模や本番運用は主張しません。

04

AI Workflow Lab

AI workflowのReliability検証。deployや利用実績は主張しません。

06 / Office Hours

Office Hours

技術について話す

平日午前の30分枠から候補時間を選べます。送信された時間枠はリクエストとして仮確保されます。内容を確認後、入力されたメールアドレスへご連絡します。

Request status

送信は面談確定ではありません。Google Calendarへの登録や自動メール通知は行いません。連絡先はAES-GCMで暗号化して保存されます。

Step 1

希望時間を選ぶ

日本時間（JST）

選択可能な時間枠を読み込んでいます…

Step 2

入力情報

すべて必須