#akibaaws

ӡ༻Ͱָ͢ΔͨΊʹઃܭͰҙࣝͯ͠ཉ͍͜͠ͱ
 ʙӡ༻୲౰ͷࢹ఺͔Βʙ ",*#""84Ԡ༻ฤ

౉ล੟߶ ‣ `ೖࣾ ‣ "84ࣄۀຊ෦
 ΦϖϨʔγϣϯ෦ॴଐ ‣ લ৬·Ͱ͸ॴҦΠϯϑϥΤϯδχΞ ‣ ൚༻ػӡ༻ɺ*41ɺ8FCαΠτӡ༻ɹFUD ‣ ເݟ͕ͪͳ"84αʔϏε
 "844ZTUFNT.BOBHFS
 ʢ΋͏ͪΐͬͱ͔Ώ͍ͱ͜Ζʹख͕ಧ͍ͯཉ͍͠ʣ ࣗݾ঺հ

ӡ༻JTԿ

ʮӡ༻ʯͱ͍͏ݴ༿ͷΠϝʔδ ੡඼EOL؅ཧ ূ໌ॻ؅ཧ υϝΠϯ؅ཧ Ϧιʔε؅ཧ IPΞυϨε؅ཧ ϧʔςΟϯά৘ใ؅ཧ ΠϯϑϥετϥΫνϟ؅ཧ ϑΝγϦςΟ؅ཧ ઃஔεϖʔε؅ཧ ిݯϦιʔε؅ཧ έʔϒϧࡏݿ؅ཧ ަ׵෦඼ࡏݿ؅ཧ ަ׵ػࡏݿ؅ཧ ҟԻ؅ཧ ۭௐ؅ཧ ࡞ۀ؀ڥ؅ཧ ೖୀࣨ؅ཧ ೖؗڐՄূ؅ཧ ܖ໿؅ཧ γϑτ؅ཧ ۓٸ࿈བྷ౰൪γϑτ؅ཧ ձࣾࢧڅ୺຤؅ཧ ձࣾࢧڅճઢ؅ཧ ܖ໿ઌରԠ σʔληϯλ ௨৴ճઢ Ϩϯλϧαʔό ϓϥΠϕʔτΫϥ΢υ ύϒϦοΫΫϥ΢υ υϝΠϯϨδετϥ VPN DNS ӡ༻จॻ࡞੒ ӡ༻จॻߋ৽ ӡ༻खॱॻ ෺ཧߏ੒ਤ ࿦ཧߏ੒ਤ ؅ཧද ఆৗ࡞ۀ ඇఆৗఆܕ࡞ۀ ඇఆܕ࡞ۀ ࢑ఆϦϦʔεରԠ ఆظϦϦʔεରԠ ܭըϦϦʔεରԠ ϋʔυ΢ΣΞอकରԠ ઃඋఆظอकରԠ ηΩϡϦςΟ ੬ऑੑ৘ใऩू ߋ৽ܭըཱҊ ߋ৽ܭը࣮ࢪ OSߋ৽ରԠ ϛυϧ΢ΣΞߋ৽ରԠ AbuseରԠ ඃAbuseରԠ ໰߹ͤରԠ ۤ৘ରԠ ۓٸϦϦʔεରԠ ϋʔυ΢ΣΞো֐ରԠ ϕϯμʔमཧରԠ ෦඼ަ׵ ϋϯμ෇͚ ؂ࢹઃఆ ϞχλϦϯά Ϧιʔε෼ੳ ΩϟύγςΟ༧ଌ ύϑΥʔϚϯενϡʔχϯά KPI෼ੳ ίετܭࢉ ߋ৽ίϯςϯπͷ։ൃ ௥Ճίϯςϯπͷ։ൃ ɿɹɹ ӡ༻ ؅ཧ υΩϡϝϯτ ରԠɾอक ো֐ରԠ ؂ࢹ ӡӦ

ӡ༻˓˓˓ ӡ༻ ≠ ΦϖϨʔγϣϯ

τϥσΟγϣφϧ΢ΥʔλʔϑΥʔϧΠϝʔδ http://01.gatag.net/0003159-free-photo/ ※ը૾͸ΠϝʔδͰ͢

τϥσΟγϣφϧ։ൃΠϝʔδ اը ։ൃ ӡ༻ https://www.irasutoya.com/ ※ը૾͸ΠϝʔδͰ͢

τϥσΟγϣφϧεέδϡʔϧ஗ԆΠϝʔδ https://www.irasutoya.com/ https://www.data.jma.go.jp/svd/eqev/data/tsunami/generation.html ※ը૾͸ΠϝʔδͰ͢

スケジュール遅延することの影響 ‣運⽤のための準備ができない ‣ドキュメント未整備が原因でいろんなことが ‣運⽤設計不⾜であんなことやこんなことまで ‣「いざとなったら運⽤でカバー」というパワーワード ‣リリース品質の低下 = 障害が起こりやすくなる ‣関係者と連絡が取りづらくなる ‣・・・ https://www.irasutoya.com/ ※ը૾͸ΠϝʔδͰ͢

ؓ࿩ٳ୊ ゲームにおける ローカライズ （翻訳・多⾔語化） 運⽤ is 何

ͳͥήʔϜͷ௿඼࣭ͳϩʔΧϥΠζ͸ੜ·Εͯ͠·͏ͷ͔ɻ
 όλϑϥΠɾΤϑΣΫτ͔ΒݟΔ໰୊ͷݪҼ https://jp.automaton.am/articles/localizetalk/20180715-72007/

ͳͥήʔϜͷ௿඼࣭ͳϩʔΧϥΠζ͸ੜ·Εͯ͠·͏ͷ͔ɻ
 όλϑϥΠɾΤϑΣΫτ͔ΒݟΔ໰୊ͷݪҼ DPOU 開発を 1 か⽉のばしても、リリース⽇はずらしたくな いのも本⾳です。予算を追加せずスケジュールを延期 できないとなると、どこかのプロセスを縮めなければ ならない。そこで短縮の対象となるのが、ローカライ ズの作業です。ローカライズ作業はまだスタートして いないにもかかわらず、最初から 1 か⽉のカットした 状態でスタートすることになります。 https://jp.automaton.am/articles/localizetalk/20180715-72007/ l

τϥσΟγϣφϧൺᄻදݱɿՆٳΈͷ॓୊ https://www.irasutoya.com/ 7/20 8/31

ͻΏͻΐ͏͛Μɿ https://www.google.com/search?q=%E3%81%BC%E3%81%8F%E3%81%AE%E3%81%AA%E3%81%A4%E3%82%84%E3%81%99%E3%81%BF+8%E6%9C%8832%E6%97%A5

ઌਓͷ஌ܙ http://rinjinyabai.com/archives/34850769.html

%FW0QT https://ja.wikipedia.org/wiki/DevOps

%FW0QT DPOU https://ja.wikipedia.org/wiki/DevOps

%FW0QT͸جຊ֓೦ https://www.irasutoya.com/

DevOpsは基本概念 (cont.) ‣SRE = DevOpsを前提にエラーバジェットの考え⽅を加えたもの ‣DevSecOps = Securityの⼤切さを強調したもの ‣コンテナ(Docker以降) = DevOpsの強⼒な武器 ‣クラウドインフラ, FaaS, CaaS, Serverless = 同上 ‣⾃動化・Infrastructure as Code = 同上 ‣Immutable Infrastructure, B/G Deployment = 同上 ‣CI/CD （以下略 https://www.irasutoya.com/

No content

https://ja.wikipedia.org/wiki/DevOps

λΠτϧʢ࠶ܝʣ ",*#""84Ԡ༻ฤ ӡ༻Ͱָ͢ΔͨΊʹઃܭͰҙࣝͯ͠ཉ͍͜͠ͱ
 ʙӡ༻୲౰ͷࢹ఺͔Βʙ

݁࿦ 8"࣮ફ͍ͯͩ͘͠͞ https://store.line.me/stickershop/product/3998375

%FWFMPQFST*0ʢએ఻ʣ

No content

https://store.line.me/stickershop/product/3998375

λΠτϧʢ࠶ܝʣ ",*#""84Ԡ༻ฤ ӡ༻Ͱָ͢ΔͨΊʹઃܭͰҙࣝͯ͠ཉ͍͜͠ͱ
 ʙӡ༻୲౰ͷࢹ఺͔Βʙ

ΤϥʔόδΣοτతͳߟ͑ํ

エラーバジェット的な考え⽅ ‣「悲観的に設計(準備)し、楽観的に運⽤(実⾏)せよ」 ‣後戻り出来ない場⾯での格⾔ ‣考え⽅⾃体は⼤切だが、ある程度のエラーを許容する ことでいろいろなものが短縮できる ‣過度にエラーを恐れずに新機能をリリースできる ‣運⽤してて⾜りないものがあったら実装しちゃいなよ︕

稼働率 A = E[uptime] E[uptime] + E[downtime] ‣uptime と downtime で計算 ‣downtime は 1回あたりの平均復旧時間(MTTR)とその回数の積 ‣MTTRが短ければ、稼働率を落とさずに回数を増やして良い︕ ‣ぶっちゃけMTTRが0.1秒以下だったら落とし放題では︖︖（極論 ‣短いダウンタイムとリトライ復旧は、遅いことと区別がつかない（ユーザ⽬線） ‣無視して良いわけでは無い（別の障害の兆候かも︖）

ϑΣΠϧηʔϑ

ϑΣΠϧηʔϑͱ͍͏ઃܭࢥ૝ ‣異常が発⽣（フェイル）しても安全（セーフ）である ‣データロスが起きない ‣リトライで復元する etc... ‣よく⾔われる例 = 踏切の遮断機、⽊こりは斜⾯の上から⽊を切る etc... ‣異常系の対応⼿順・体制が整備されていることも広義の「セーフ」 ‣フールプルーフ = そもそも異常な操作ができない（権限、UI） ‣フォルトトレラント = 障害発⽣時でも縮退運転で継続 = 冗⻑性

ࢀߟɿηʔϑ΢ΣΞ ‣事故には必ず原因がある ‣ヒューマンエラーというエラーはない ‣ヒューマンエラーは必ず発⽣するので、 それを⾒込んでいないことこそがエラー https://www.shoeisha.co.jp/book/detail/9784798116846

まとめ︓運⽤で楽するために設計で意識して欲しいこと ‣運⽤ ≠ オペレーション ‣ リリース後にやるべきことは多岐に及びます ‣ ⻑い開発サイクルは、下流に負荷が集中しがちとなる（構造的な問題） ‣Well-Architected な考え⽅ ‣ 早いサイクルでの構築・デプロイ、⾜りない機能の追加実装 ‣ 開発と運⽤の強い連携 = DevOps ‣エラーバジェット的な考え⽅ ‣ 稼働率を落とさずリリース頻度を上げるために ‣フェイルセーフ ‣ 異常が発⽣しても障害を起こさない設計 ‣ 「ヒューマンエラーというエラーはない」

そのための道具 ‣コンテナ(Docker以降) ‣マネージドインフラ、Serverless ‣SaaS ‣UI/UX ‣適切な権限設定 ‣CI/CD ‣機械化・⾃動化 ‣ロギング・モニタリング 等々

そのための道具 ‣コンテナ(Docker以降) <- ECS, EKS ‣マネージドインフラ、Serverless <- ‣SaaS <- ‣UI/UX ‣適切な権限設定 <- IAM ‣CI/CD <- Code兄弟 ‣機械化・⾃動化 <- ‣ロギング・モニタリング <- CloudWatch

ٹੈओ http://rinjinyabai.com/archives/34850769.html

No content