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
Tadahiro Ishisaka
May 05, 2023
Technology
0
68
インストール100回だ(゚Д゚)ゴルァ!! プログラマがインフラ技術を知らなければならないわけ
プログラマが仮想レイヤーであるインフラを知らないことによる悲劇と、そこをどうしていこうかと言う話。
まぁ古い話ではある。
Tadahiro Ishisaka
May 05, 2023
Tweet
Share
More Decks by Tadahiro Ishisaka
See All by Tadahiro Ishisaka
開発から見たWindowsの国際化機能
ishisaka
0
180
Other Decks in Technology
See All in Technology
Context Engineeringが企業で不可欠になる理由
hirosatogamo
PRO
3
660
AIエージェントを開発しよう!-AgentCore活用の勘所-
yukiogawa
0
190
量子クラウドサービスの裏側 〜Deep Dive into OQTOPUS〜
oqtopus
0
150
プロポーザルに込める段取り八分
shoheimitani
1
630
Agile Leadership Summit Keynote 2026
m_seki
1
670
Context Engineeringの取り組み
nutslove
0
380
Webhook best practices for rock solid and resilient deployments
glaforge
2
310
20260208_第66回 コンピュータビジョン勉強会
keiichiito1978
0
190
AzureでのIaC - Bicep? Terraform? それ早く言ってよ会議
torumakabe
1
600
OCI Database Management サービス詳細
oracle4engineer
PRO
1
7.4k
日本の85%が使う公共SaaSは、どう育ったのか
taketakekaho
1
240
ブロックテーマでサイトをリニューアルした話 / 2026-01-31 Kansai WordPress Meetup
torounit
0
480
Featured
See All Featured
A Soul's Torment
seathinner
5
2.3k
Marketing to machines
jonoalderson
1
4.6k
Exploring the relationship between traditional SERPs and Gen AI search
raygrieselhuber
PRO
2
3.6k
Fireside Chat
paigeccino
41
3.8k
Claude Code どこまでも/ Claude Code Everywhere
nwiizo
61
52k
コードの90%をAIが書く世界で何が待っているのか / What awaits us in a world where 90% of the code is written by AI
rkaga
60
42k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
122
21k
Are puppies a ranking factor?
jonoalderson
1
2.7k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
5.8k
<Decoding/> the Language of Devs - We Love SEO 2024
nikkihalliwell
1
130
How GitHub (no longer) Works
holman
316
140k
Reflections from 52 weeks, 52 projects
jeffersonlam
356
21k
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.