インフラ

システムをどう動かすか、エラー時どう対処するかなどを分かりやすく書き留めた資料。調理マニュアルのように、誰が見ても同じ手順で再現できるようにする。一人が頭で覚えているだけでは、休んだとき大変だからね。

サーバー側が利用者の状態（ログイン情報など）を覚えず、リクエストごとに完全に独立して処理する考え方。たとえばお店の店員が毎度「こんにちは、お名前は？」と聞いて調理するスタイル。ユーザー情報を持たないぶん、どのサーバーに行っても対応できるから...

シップの船底をいくつか仕切り（バルクヘッド）で分割して、浸水しても全体が沈まないようにするデザイン。ITでは一部サービスが壊れても他の部分に波及しないよう独立させる考え方。マイクロサービスが互いを巻き込まないために必要なんだ。

本格的に検証する前に、主要な機能がちゃんと起動するかだけサッと確認するテスト。料理で言うと、味見する前に火が通ってるか見て、煙が出てないか確認する感じ。おかしいところがあれば早期にわかるから、詳しいテストに進む前に助かるんだ。

Webブラウザとサーバーが“一度つないだら継続的にやり取り”できる仕組み。チャットアプリで、サーバーが新メッセージをプッシュ通知してくれる感じ。普通のHTTPだとクライアントが毎回「ありますか？」と聞くけど、WebSocketは「届いたらす...

トラブルが起きたとき「問題はどこにあるの？」を段階的に探すこと。テレビが映らないとき、まず電源コードを確認し、次にリモコン電池を見て、アンテナをチェック…みたいに原因を絞っていく。漠然と全部疑うと大変なので、手順を決めるのがコツ。

ユーザーが実際に触って「思った通り動く？」を確かめる最後のテスト。家を建てた後の内覧会みたいに「ちゃんと使いやすいですか？」と見てもらう。ここでOKが出れば晴れてリリースに近づくんだ。

外部からの問い合わせを受け取り、内部のサービスに分配する“総合窓口”。例えばアプリが「商品情報を教えて」と言えば、それを受け取って商品データベースへ尋ねる。サービスの数が増えてもゲートウェイが窓口として整理してくれるから、外部から見るとアク...

HTMLや画像、CSS、JavaScriptなど、リクエストしても中身が変わらない“固定”のファイルを指す。学校の張り紙のように、一度作ったら読み取るだけ。これをオブジェクトストレージやCDNに置けば、高速配信がしやすいんだ。

運用中のシステムを変えたいとき「この部分をこう直したいです」と正式に申し込むこと。学校で備品を買い足したい場合、まず先生に申請書を出して許可をもらうイメージかな。いきなり勝手に変えると問題が起きても追跡できないから、手順が大事なんだ。