Ercan Ermis

Ercan Ermisです。オランダを拠点とするシニアクラウドプラットフォームエンジニアです。クラウド、AWS、EKS、Terraform、可観測性、そしてシステムが午前3時に稼働し続けるかどうかを決めるプラットフォームエンジニアリングの判断について書いています。

ここに至るまで

人生で最初のコンピュータは、Floppy AとFloppy Bという5.25インチのフロッピードライブを2基搭載したAmstradでした。1986年に父が事業のために買ったものです。本当の意味で恋に落ちたのは1998年、小学4年生のときでした。学校のコンピュータ室にあったWindows 95のマシンの1台に、先生がLinuxをインストールして「これはLinuxといって、フリーソフトウェアだよ」と言ったのです。そして黒い画面にPac-Manが現れた瞬間、私はもう抜け出せませんでした。

なぜこれは動くのか。実際にはどうやって動いているのか。他に何ができるのか。どうすれば違うやり方でやらせられるのか。30年以上経った今も、私はこの4つの問いを繰り返し、キーボードの前に座り続けています。コンピュータの前で過ごす時間は、今も昔も私が最も心地よく、最も穏やかでいられる場所です。このサイトのプラットフォームエンジニアリングの仕事は、その問いのループを数十年回し続けた結果として生まれたものです。

このサイトの投稿は、スライドではなく実際のプロダクションシステムから来ています。BMW Bankでの24時間365日の可用性要件を伴うバンキングリスク計算。16年前のオンプレミスベッティングプラットフォームをダウンタイムゼロ、データ損失ゼロでAWSに移行した話。Miniclipを通じた獲得規模のマルチプレイヤーモバイルゲーム。唯一のエンジニアとしてエンドツーエンドで担当したライブストリーミングインジェストパイプライン。それぞれの経験が傷跡を残し、その傷跡が投稿になります。

私の働き方

Platform Engineering、SRE、DevOpsは私にとって1つの仕事であり、3つではありません。ターゲットアーキテクチャを設計し、それをプロビジョニングするTerraformを書き、その上にデプロイするCI/CDを構築し、その結果に対してポケベルを持ち続けます。別々の役割への分割は組織図に過ぎず、実際の仕事は1つのループです。私はそのループの中から書いています。

バイアスは以下に向かっています：

  • チームごとの特注インフラではなく、再利用可能なモジュールと舗装された道。
  • 後付けではなく、最小権限IAM、KMS、ネットワーク分離をデフォルトに。
  • レイテンシやエラー率と同じダッシュボードでのコスト意識。
  • 正直な失敗モード分析。「大丈夫だろう」はSLOではありません。

ここで見つかるもの

ほとんどの投稿は3つのカテゴリのいずれかに該当します：

  • プロダクション環境のAWSとEKS。 クラスタの運用、ノードグループのサイジング、実際にスケールするIAMパターン、ネットワーキングの落とし穴、トラブルのないコントロールプレーンのアップグレード。
  • 組織規模でのTerraformとTerragrunt。 モジュール境界、状態所有権、ドリフト、レビュー自動化、複利を生む退屈なインフラ。
  • 可観測性と信頼性。 Prometheus、Grafana、CloudWatch、構造化ログ、作成者以外の誰かが実際に従えるランブック。

私が想定している読者は、既にAWS CLIを知っていて、既にどこかでKubernetesを運用していて、私が遭遇した明らかでない部分、トレードオフ、失敗モードを知りたいエンジニアです。

資格とコミュニティ

  • AWS Certified Solutions Architect, Associate。
  • 2022年からAWS Community Builder。
  • Claude Community NLのロッテルダムチャプターオーガナイザー。初回ロッテルダムイベントは近日開催予定です。meetup.com/claude-rotterdamをフォローしてください。
  • Izmir Yazilim Agi創設者（1,239名のメンバー、57回のイベント）。
  • AI関連の執筆とニュース: ercan.aiは長文形式、news.ercan.aiは短文形式の速報。
  • UptimeCoach、20のAWSリージョンにまたがってプロビジョニングされた個人SaaSラボで、動作するマルチリージョンリファレンスです。

コンサルティングとアドバイザリー

毎年少数のコンサルティング案件を引き受けており、心から楽しんでいます。チーム、スタック、制約の多様性が、私自身のプラットフォーム感覚を鋭く保ちます。クライアントのために行う仕事は、このサイトの執筆に直接フィードバックされ、その逆もまた然りです。

チームとの協働方法：

  • プラットフォームエンジニアリングアドバイザリー。 「ただのTerraformと祈り」では機能しなくなる地点にチームが差し掛かっています。モジュール境界、状態所有権、CI/CD設計、最小権限IAM、そしてプラットフォームをコストセンターではなく製品に変える運用モデルについて支援します。
  • AWSコスト最適化。 「Savings Plansを買って終わり」ではない、本物の最適化。請求書を1行ずつ精査し、無駄を特定のワークロードまで追跡し、再構築します。ほとんどの案件で、アプリケーションコードに一切触れることなく30〜50%を見つけ出します。
  • 暫定プラットフォームリード。 リード不在、または重要な成長段階を迎えているチーム。一定期間参加し、技術的方向性を設定し、Paved Roadを構築し、長期的なリードの採用または昇進を支援します。
  • 移行とモダナイゼーション。 レガシーをAWSにリフト、モノリスをサービスに分解、またはマルチアカウントの混乱を整理。どの部分が痛むか、そして痛まないように順序付ける方法を知るのに十分な経験があります。

私がコンサルティングを行う領域の全体像：AWS、クラウドアーキテクチャ、CI/CDパイプライン、Linux、GitHubおよびGitLabツーリング、TerraformとTerragrunt、KubernetesとEKS、可観測性、コスト最適化、移行、そしてそれら全体を支えるプラットフォームエンジニアリングの運用モデル。プロダクションのクラウドアカウントやビルドパイプラインで動いているものなら、すべて対象範囲です。

小規模で集中的な案件。一度に1つか2つ。取り組んでいることが、私がここで書いている種類のことに似ているなら、LinkedInでご連絡ください。問題とチームの規模についての短いメッセージだけで始められます。

次に読む