Upgrade to Pro — share decks privately, control downloads, hide ads and more …

インストール100回だ(゚Д゚)ゴルァ!! プログラマがインフラ技術を知らなければならないわけ

Sponsored · Ship Features Fearlessly Turn features on and off without deploys. Used by thousands of Ruby developers.

インストール100回だ(゚Д゚)ゴルァ!! プログラマがインフラ技術を知らなければならないわけ

プログラマが仮想レイヤーであるインフラを知らないことによる悲劇と、そこをどうしていこうかと言う話。
まぁ古い話ではある。

Avatar for Tadahiro  Ishisaka

Tadahiro Ishisaka

May 05, 2023
Tweet

More Decks by Tadahiro Ishisaka

Other Decks in Technology

Transcript

  1. Fact 1 • ネットワーク切断が考慮されていない ネットワーク分散システム – クライアントが数分固まってエラー – RPCを使っているのに相手がいないことを前 提としない(DCOM)

    – このため、障害時の調査やデバッグが当て外 れで復旧に多大な時間がかかる。(ハブのス テータス見れば一瞬だった) • 本質的なエラー原因はハブの故障 – 最終的にユーザーは別の会社に修正を依頼し た。
  2. Fact1の本質的な原因 • DCOMという分散オブジェクトを利用してい るが、クライアントプログラムを作ったプロ グラマがC/Sを理解できていなかった。 – ローカルでの開発・デバッグ – フレームワークの仕組みについての無知 –

    テストの不足だが、そもそもこれではテスト項目 として洗い出しできない – エラーメッセージもユーザーに対して適切に提供 できていない • DCOMのHRESULTがそのままメッセージボックスに。
  3. Fact2の本質的原因 • プログラマがRDBMSをそもそもわかって なかった。 – サーバーというものが移動されるという前提 が共有できていない • このため接続設定を変更可能にするという発想が 無かった。

    – プログラマがそもそもフレームワークとツー ル任せで接続設定等について理解ができてい ない。 – プログラムの修正が必要になった
  4. Fact3 • 試験環境では正しく動作し、レスポンスも十 分だたしステムが、実行環境に移したら、シ ステムのターンアラウンドに数分もかかって しまい使い物にならない。 – セッションごとにRDBMSが動作するサーバーの負 荷率が数分間100%になる –

    ついでにストレージサーバーの負荷率も急上昇 – ストレージサーバーを共有する他システムに影響 が出始める – ユーザーが結局RDBMSチューニングのスペシャリ ストをお願いし、適切なチューニングをして今日 できる範囲にターンアラウンド時間を改善した。
  5. プログラマがインフラを知らない と何が起きるのか • 設計の不足 – 非機能要件に対する設計不足 • 障害やパフォーマンスに対する設計 • テストの不足

    – 非機能要件に対すテスト不足 • 障害やパフォーマンスに対する試験 • 結果として不完全なソフトウェアシステ ム
  6. ソフトウェアと ソフトウェアシステム • ソフトウェアシステム – 複数のソフトウェアが相互連携して動くのが ソフトウェアシステム – 一つのプログラムでは完結できない •

    すべて自分だけですまない • 相手はいないかもしれない • 相手に負荷をかければうまくシステムとして動か ない • 相手との距離感を理解できているか。
  7. ビルド環境の構築と管理 • ビルド環境を構築させる – OSのインストール – ネットワーク環境の設定 – 開発環境のインストール –

    ユーザー設定 • ビルド環境のお守り – ユーザー管理 – バックアップ – 設定変更 • 単独サーバーの構築と管理を学ぶ
  8. 丁稚 • OJT – で済まさない – 論理的な点をどこまで教え込むか – やってみせる –

    やらせてみる – 背中を見せる • 先輩の姿勢が後輩の姿勢 • 丁稚に出す – 社内に管理部門やサービス部門があれば 帰ってくる約束で配転してみる。