Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
インストール100回だ(゚Д゚)ゴルァ!! プログラマがインフラ技術を知らなければならないわけ
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Tadahiro Ishisaka
May 05, 2023
Technology
76
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
インストール100回だ(゚Д゚)ゴルァ!! プログラマがインフラ技術を知らなければならないわけ
プログラマが仮想レイヤーであるインフラを知らないことによる悲劇と、そこをどうしていこうかと言う話。
まぁ古い話ではある。
Tadahiro Ishisaka
May 05, 2023
More Decks by Tadahiro Ishisaka
See All by Tadahiro Ishisaka
開発から見たWindowsの国際化機能
ishisaka
0
220
Other Decks in Technology
See All in Technology
Redmine 7.0で私が開発した新機能の狙いと背景
vividtone
1
120
動画配信アプリでの Engage SDK 導入 — TVer Android が Play ストアにコンテンツを届けるまで
techtver
PRO
0
150
AI時代のAPI品質を支えるガードレール / API Guardrails for API quality in the AI era
yokawasa
1
170
作り直せるコードは迅速に 作り直せないDBは慎重に - AI時代のプロダクトエンジニアが「判断の不可逆性」で開発速度を変える話
kinosuke01
0
280
[DroidKaigi 2026] Making UI specifications visible: Android UI development in the AI agent era supported by Compose Screenshot Testing and galleries
syarihu
0
610
Amazon S3 Tablesに全部任せてみた結果——コンパクション/スナップショット管理は本当に手放せるか
shigeruoda
0
420
ペアプロの価値はコードを書くことだけじゃない
codmoninc
PRO
0
140
GuardDuty 検知対応を DevOps Agent で効率化しようとしている話 / GuardDuty Investigations with DevOps Agent
masahirokawahara
1
340
AIに丸投げしないトイル削減 / Eliminating Toil Without Leaving It All to AI
kohbis
4
1k
現場に行くだけでは足りない——プロダクトエンジニアが業務の流れを捉える観点と、その鍛え方
takumiengineering
0
330
Podは生きているのにGoだけが落ちる:GOGCとGOMEMLIMITで追うInvisible OOM Killの謎
tkc66buzz
0
180
2026-09-11 【Snowflake World Tour Tokyo 2026】Snowflakeを起点に、AI Agentが自律稼働し続ける未来へ / Driving AI Agents with Snowflake
civitaspo
0
210
Featured
See All Featured
Visual Storytelling: How to be a Superhuman Communicator
reverentgeek
2
650
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
4.7k
Done Done
chrislema
186
16k
Designing for Timeless Needs
cassininazir
1
470
Avoiding the “Bad Training, Faster” Trap in the Age of AI
tmiket
0
230
SEO for Brand Visibility & Recognition
aleyda
0
4.7k
Breaking role norms: Why Content Design is so much more than writing copy - Taylor Woolridge
uxyall
1
400
A brief & incomplete history of UX Design for the World Wide Web: 1989–2019
jct
2
500
WENDY [Excerpt]
tessaabrams
12
39k
Darren the Foodie - Storyboard
khoart
PRO
3
3.9k
Why Your Marketing Sucks and What You Can Do About It - Sophie Logan
marketingsoph
0
400
Discover your Explorer Soul
emna__ayadi
2
1.3k
Transcript
第6回静岡ITPro勉強会インフラ部 インストール100回だ(゚Д゚)ゴルァ!! プログラマがインフラ技術を 知らなければならないわけ
プログラマに インフラ技術が必要なわけ
えーマジ インフラ知らない!? キモーイ インフラを知らないのが許され るのはコーダーまでだよね! キャハハハハハハ
Fact 1 • ネットワーク切断が考慮されていない ネットワーク分散システム – クライアントが数分固まってエラー – RPCを使っているのに相手がいないことを前 提としない(DCOM)
– このため、障害時の調査やデバッグが当て外 れで復旧に多大な時間がかかる。(ハブのス テータス見れば一瞬だった) • 本質的なエラー原因はハブの故障 – 最終的にユーザーは別の会社に修正を依頼し た。
Fact1の本質的な原因 • DCOMという分散オブジェクトを利用してい るが、クライアントプログラムを作ったプロ グラマがC/Sを理解できていなかった。 – ローカルでの開発・デバッグ – フレームワークの仕組みについての無知 –
テストの不足だが、そもそもこれではテスト項目 として洗い出しできない – エラーメッセージもユーザーに対して適切に提供 できていない • DCOMのHRESULTがそのままメッセージボックスに。
Fact2 • クライアントからの呼び出しに応じて RDBMS上のデータを読み書きするサービ スがあったが、ある日RDBMSのサーバー を統合化したのだが、それ以後システム が動作しない。 – シスアドがRDBMS接続の設定ファイルを探し たが見つからず、変更でいない
– 仕様書を確認したが起動パラメーター等もな し
Fact2の本質的原因 • プログラマがRDBMSをそもそもわかって なかった。 – サーバーというものが移動されるという前提 が共有できていない • このため接続設定を変更可能にするという発想が 無かった。
– プログラマがそもそもフレームワークとツー ル任せで接続設定等について理解ができてい ない。 – プログラムの修正が必要になった
Fact3 • 試験環境では正しく動作し、レスポンスも十 分だたしステムが、実行環境に移したら、シ ステムのターンアラウンドに数分もかかって しまい使い物にならない。 – セッションごとにRDBMSが動作するサーバーの負 荷率が数分間100%になる –
ついでにストレージサーバーの負荷率も急上昇 – ストレージサーバーを共有する他システムに影響 が出始める – ユーザーが結局RDBMSチューニングのスペシャリ ストをお願いし、適切なチューニングをして今日 できる範囲にターンアラウンド時間を改善した。
Fact3の事実 • プログラマがSQL言語への知識が薄く、経験 もほぼ無かった • ORMフレームワークを使用し、SQLのクエ リーはノーチューン、テーブルもORM任せで インデックス処理等もされていなかった – 毎回全テーブルスキャンするので遅いのは当たり
前。 • プログラマに大規模なデータになったときに 何が必要か想像できれば事前に何とかできた はず。
プログラマがインフラを知らない と何が起きるのか • 設計の不足 – 非機能要件に対する設計不足 • 障害やパフォーマンスに対する設計 • テストの不足
– 非機能要件に対すテスト不足 • 障害やパフォーマンスに対する試験 • 結果として不完全なソフトウェアシステ ム
ソフトウェアと ソフトウェアシステム • ソフトウェアシステム – 複数のソフトウェアが相互連携して動くのが ソフトウェアシステム – 一つのプログラムでは完結できない •
すべて自分だけですまない • 相手はいないかもしれない • 相手に負荷をかければうまくシステムとして動か ない • 相手との距離感を理解できているか。
自称プログラマの現実 • OSのネットワーク設定ができない • OSのインストールができない、したこと 無い。 • ネットワークとか知らない。(のに自称 WEB系プログラマ。PHPは何となくかける らしい)
• RDBMSってなに?おいしいの? • 配線ができない
そもそもどうやって 自分の書いたコードが 動いているかわかってね-
想像力を持つためのインフラ知識 • 以上の問題は究極的にはプログラマがソ フトウェアシステムに対してどれだけの 想像力を持ち得るのかという問題 • 想像力は山勘では無い – 知識が無いことは想像できない –
経験が無いことは想像できない • プログラマが失敗しない(させない)ために はインフラ知識と経験が必要
プログラマにどのように インフラ技術を教えるか
目的をしっかり持つ • 目的はインフラエンジニアになることで は無い • ソフトウェアシステムの設計・構築を可 能にするための知見を持たせるのが目的 – 深掘りさせすぎてもいけない –
できるだけまんべんなく
ビルド環境の構築と管理 • ビルド環境を構築させる – OSのインストール – ネットワーク環境の設定 – 開発環境のインストール –
ユーザー設定 • ビルド環境のお守り – ユーザー管理 – バックアップ – 設定変更 • 単独サーバーの構築と管理を学ぶ
テスト環境の構築 • 複数のサーバ・クライアントからなるシ ステムの構築と運用 • ネットワークの物理的な接続、SWハブや ルーターの設定等も段階を踏んでやらせ る。 • 場合によっては理論的なところの講義と
かも必要。
丁稚 • OJT – で済まさない – 論理的な点をどこまで教え込むか – やってみせる –
やらせてみる – 背中を見せる • 先輩の姿勢が後輩の姿勢 • 丁稚に出す – 社内に管理部門やサービス部門があれば 帰ってくる約束で配転してみる。
数をこなすことで わかることもある インスコ100回だ ( ゚Д゚)ゴルァ!
経験は積まないといけない • 本だけでは駄目 • 体で覚えることも必要 • 数をこなすことで見えてくることもある • 少ない機会の中でいかにインフラ的経験 を積ませるかが吉
本人と教える側のツール • ITスキル標準 – 目指すはITアーキテクト – 何を目指すのかの目標設定 http://www.ipa.go.jp/jinzai/itss/index.html
IT技術者を目指す • そもそもプログラマと管理者の違いなん て元々無かった • システムが大規模になったので分業化し た • 両方に目を配れるIT技術者を目指そう
*宣伝* • 2/18(土) Windows Azureの勉強会やります! • 第1回JAZUG静岡勉強会/第8回静岡ITPro勉強会 – 場所:静岡県立大 –
http://www.zusaar.com/event/199062
No Code, No Life.