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
63
インストール100回だ(゚Д゚)ゴルァ!! プログラマがインフラ技術を知らなければならないわけ
プログラマが仮想レイヤーであるインフラを知らないことによる悲劇と、そこをどうしていこうかと言う話。
まぁ古い話ではある。
Tadahiro Ishisaka
May 05, 2023
Tweet
Share
More Decks by Tadahiro Ishisaka
See All by Tadahiro Ishisaka
開発から見たWindowsの国際化機能
ishisaka
0
150
Other Decks in Technology
See All in Technology
Autonomous Database Serverless 技術詳細 / adb-s_technical_detail_jp
oracle4engineer
PRO
18
52k
Delegate authentication and a lot more to Keycloak with OpenID Connect
ahus1
0
240
モダンな現場と従来型の組織——そこに生じる "不整合" を解消してこそチームがパフォーマンスを発揮できる / Team-oriented Organization Design 20250825
mtx2s
2
230
プロジェクトマネジメントは不確実性との対話だ
hisashiwatanabe
0
180
[CVPR2025論文読み会] Linguistics-aware Masked Image Modelingfor Self-supervised Scene Text Recognition
s_aiueo32
0
200
Exadata Database Service on Dedicated Infrastructure セキュリティ、ネットワーク、および管理について
oracle4engineer
PRO
1
340
生成AI利用プログラミング:誰でもプログラムが書けると 世の中どうなる?/opencampus202508
okana2ki
0
180
なごミュ@SPAJAM2025 第二回予選
1901drama
0
110
サイボウズフロントエンドの横断活動から考える AI時代にできること
mugi_uno
3
1.3k
あなたの知らない OneDrive
murachiakira
0
190
Mackerel in さくらのクラウド
cubicdaiya
1
390
Claude Code x Androidアプリ 開発
kgmyshin
1
480
Featured
See All Featured
Embracing the Ebb and Flow
colly
86
4.8k
Become a Pro
speakerdeck
PRO
29
5.5k
Producing Creativity
orderedlist
PRO
347
40k
Being A Developer After 40
akosma
90
590k
Bash Introduction
62gerente
614
210k
Unsuck your backbone
ammeep
671
58k
The Pragmatic Product Professional
lauravandoore
36
6.8k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
30
9.6k
Gamification - CAS2011
davidbonilla
81
5.4k
Thoughts on Productivity
jonyablonski
69
4.8k
GraphQLとの向き合い方2022年版
quramy
49
14k
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.