153 lines
12 KiB
HTML
153 lines
12 KiB
HTML
|
<!DOCTYPE html>
|
||
|
|
<html lang="en">
|
||
|
|
<head>
|
||
|
|
<style id="fort-styles">
|
||
|
|
[data-fort]{font:inherit;color:inherit}
|
||
|
|
ul[data-fort]{list-style:none;margin:0;padding:0;display:flex;flex-direction:column;gap:.45em}
|
||
|
|
[data-fort] li{margin:0;padding:0;line-height:1.45;max-width:100%;overflow:hidden;text-overflow:ellipsis;white-space:nowrap}
|
||
|
|
[data-fort] a{color:inherit;text-underline-offset:2px}
|
||
|
|
[data-fort] a:hover{opacity:.72}
|
||
|
|
[data-fort] .src,[data-fort] .fm-type{opacity:.6;font-size:.85em}
|
||
|
|
.fort-citizen{display:flex;flex-direction:column;gap:.4em}
|
||
|
|
.fort-citizen .fc-name{font-weight:600}
|
||
|
|
.fort-citizen .fc-pages{list-style:none;margin:0;padding:0;display:flex;flex-direction:column;gap:.3em}
|
||
|
|
.fort-media,.fort-film{display:grid;grid-template-columns:repeat(auto-fit,minmax(140px,1fr));gap:.6em}
|
||
|
|
.fort-film{list-style:none;margin:0;padding:0}
|
||
|
|
.fort-film li{overflow:visible;white-space:normal}
|
||
|
|
.fort-film a{display:flex;flex-direction:column;gap:.3em;text-decoration:none}
|
||
|
|
.fort-media img,.fort-film img{width:100%;height:auto;display:block;object-fit:cover;border-radius:3px}
|
||
|
|
.fort-film img{aspect-ratio:16/10}
|
||
|
|
.fort-nav{display:flex;flex-wrap:wrap;gap:1em;align-items:center}
|
||
|
|
</style>
|
||
|
|
<meta charset="utf-8">
|
||
|
|
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||
|
|
<title>Principles — Alan Pazmino</title>
|
||
|
|
<meta property="og:type" content="website">
|
||
|
|
<meta property="og:title" content="Principles — Alan Pazmino">
|
||
|
|
<meta property="og:description" content="I">
|
||
|
|
<meta property="og:image" content="https://images.pexels.com/photos/5161816/pexels-photo-5161816.jpeg?auto=compress&cs=tinysrgb&dpr=2&h=650&w=940">
|
||
|
|
<meta property="og:url" content="https://alan-pazmino.4ort.net/principles.html">
|
||
|
|
<meta name="twitter:card" content="summary_large_image">
|
||
|
|
<meta name="description" content="I've sat in post-incident reviews where the network diagram showed triple-redundant paths and the engineer said, "all three went down." Then I'd ask what…">
|
||
|
|
<style>
|
||
|
|
@import url('https://fonts.googleapis.com/css2?family=JetBrains+Mono:wght@400;700&family=IBM+Plex+Mono:wght@400;600&display=swap');
|
||
|
|
* { margin: 0; padding: 0; box-sizing: border-box; }
|
||
|
|
:root { --bg: #0a0a0a; --fg: #d4a017; --fg-dim: #8b6914; --accent: #e8b828; --border: #2a2a2a; --panel: #111111; }
|
||
|
|
body { background: var(--bg); color: var(--fg); font-family: 'JetBrains Mono', 'IBM Plex Mono', monospace; font-size: 14px; line-height: 1.6; max-width: 900px; margin: 0 auto; padding: 2rem 1.5rem; }
|
||
|
|
::selection { background: var(--accent); color: var(--bg); }
|
||
|
|
a { color: var(--accent); text-decoration: none; border-bottom: 1px solid var(--fg-dim); }
|
||
|
|
a:hover { background: var(--accent); color: var(--bg); }
|
||
|
|
.navbar { border: 1px solid var(--border); padding: 0.5rem 1rem; margin-bottom: 2rem; display: flex; justify-content: space-between; align-items: center; }
|
||
|
|
.navbar strong { color: var(--accent); font-size: 1.1rem; }
|
||
|
|
.nav-links a { margin-left: 1.5rem; font-size: 0.85rem; text-transform: uppercase; letter-spacing: 0.08em; }
|
||
|
|
header { border-bottom: 2px solid var(--fg); padding-bottom: 1.5rem; margin-bottom: 2rem; }
|
||
|
|
header h1 { font-size: 1.8rem; color: var(--accent); margin-bottom: 0.3rem; }
|
||
|
|
header .subtitle { font-size: 0.9rem; color: var(--fg-dim); text-transform: uppercase; letter-spacing: 0.12em; }
|
||
|
|
section { margin-bottom: 2.5rem; }
|
||
|
|
.section-label { font-size: 0.7rem; text-transform: uppercase; letter-spacing: 0.15em; color: var(--fg-dim); border: 1px solid var(--border); padding: 0.2rem 0.6rem; display: inline-block; margin-bottom: 1rem; }
|
||
|
|
h2 { font-size: 1.2rem; color: var(--accent); margin-bottom: 0.8rem; text-transform: uppercase; letter-spacing: 0.05em; }
|
||
|
|
h3 { font-size: 0.95rem; color: var(--fg); margin: 1rem 0 0.4rem; border-left: 3px solid var(--accent); padding-left: 0.6rem; }
|
||
|
|
p { margin-bottom: 0.8rem; }
|
||
|
|
.principle-table { width: 100%; border-collapse: collapse; margin: 1rem 0; }
|
||
|
|
.principle-table th, .principle-table td { border: 1px solid var(--border); padding: 0.5rem 0.8rem; text-align: left; font-size: 0.85rem; }
|
||
|
|
.principle-table th { background: var(--panel); color: var(--accent); text-transform: uppercase; letter-spacing: 0.08em; font-size: 0.7rem; }
|
||
|
|
.log-entry { border-left: 2px solid var(--border); padding: 0.5rem 1rem; margin: 0.8rem 0; font-size: 0.85rem; }
|
||
|
|
blockquote { border-left: 3px solid var(--fg); margin: 1rem 0; padding: 0.5rem 1rem; font-style: italic; color: var(--fg-dim); }
|
||
|
|
.field-image { margin: 1rem 0; max-width: 100%; border: 1px solid var(--border); }
|
||
|
|
.field-image img { width: 100%; display: block; filter: sepia(20%) contrast(1.05); }
|
||
|
|
.caption { font-size: 0.7rem; color: #666; text-align: right; padding: 0.3rem 0; letter-spacing: 0.04em; }
|
||
|
|
footer { border-top: 1px solid var(--border); padding-top: 1rem; margin-top: 3rem; font-size: 0.7rem; color: #555; text-transform: uppercase; letter-spacing: 0.1em; }
|
||
|
|
code { background: var(--panel); padding: 0.1rem 0.3rem; border: 1px solid var(--border); font-size: 0.8rem; }
|
||
|
|
.diagram { border: 1px solid var(--border); padding: 1.5rem; margin: 1rem 0; background: var(--panel); }
|
||
|
|
.diagram pre { margin: 0; font-size: 0.8rem; line-height: 1.4; color: var(--fg); }
|
||
|
|
</style>
|
||
|
|
<script defer src="https://analytics.4ort.xyz/script.js" data-website-id="d3ed927c-888a-4a6c-ae5f-0b1c613ddf5b"></script>
|
||
|
|
</head>
|
||
|
|
<body>
|
||
|
|
|
||
|
|
<div class="navbar">
|
||
|
|
<strong>APAZMINO//NET</strong>
|
||
|
|
<fort-nav><nav class="fort-nav" data-fort="nav"><a href="/">Alan Pazmino</a><a href="/principles.html" class="active" aria-current="page">Principles</a><a href="/signals.html">Signal Measurement Reference</a></nav></fort-nav>
|
||
|
|
<div class="nav-links">
|
||
|
|
<a href="index.html">home</a>
|
||
|
|
<a href="principles.html">principles</a>
|
||
|
|
<a href="signals.html">signals</a>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<header>
|
||
|
|
<h1>Field Principles</h1>
|
||
|
|
<div class="subtitle">Redundancy, Verification, and the Discipline of Descent</div>
|
||
|
|
</header>
|
||
|
|
|
||
|
|
<section>
|
||
|
|
<span class="section-label">A — The Redundancy Fallacy</span>
|
||
|
|
<h2>Three Paths, One Failure Mode</h2>
|
||
|
|
<p>I've sat in post-incident reviews where the network diagram showed triple-redundant paths and the engineer said, "all three went down." Then I'd ask what they shared—a common power circuit, a shared grounding plane, a single fiber conduit—and the answer was always the same thing. That's not redundancy. That's a single point of failure wearing a disguise.</p>
|
||
|
|
<p>True redundancy requires <strong>independent failure domains</strong>. Each path must fail for a reason the others cannot share. In practice, this means:</p>
|
||
|
|
<table class="principle-table">
|
||
|
|
<thead>
|
||
|
|
<tr><th>Redundancy Layer</th><th>Independence Requirement</th><th>Common Failure</th></tr>
|
||
|
|
</thead>
|
||
|
|
<tbody>
|
||
|
|
<tr><td>Path A (Primary)</td><td>Dedicated conduit, separate UPS</td><td>Backplane fault</td></tr>
|
||
|
|
<tr><td>Path B (Secondary)</td><td>Different physical route, independent power</td><td>Port failure on secondary switch</td></tr>
|
||
|
|
<tr><td>Path C (Tertiary)</td><td>Separate building entry, wireless or satellite backup</td><td>Configuration error, human factor</td></tr>
|
||
|
|
<tr><td>Shared Point of Failure</td><td colspan="2" style="color:#c44;">Power distribution, grounding, physical conduit, configuration template, firmware version</td></tr>
|
||
|
|
</tbody>
|
||
|
|
</table>
|
||
|
|
<p>The rule is simple: if Path A fails because of a power surge, Path B and C must not be on the same breaker. If Path A fails due to a firmware bug, B and C must not be running the same release. If all three paths share a conduit that a backhoe hits, you have zero paths.</p>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section>
|
||
|
|
<span class="section-label">B — The Verification Protocol</span>
|
||
|
|
<h2>Measure Twice, Trust Never</h2>
|
||
|
|
<p>Every measurement I take is cross-validated. On the bench, that means an HP 8753E network analyzer for S-parameters, a Fluke DSX-8000 for cable certification, and a logic analyzer for protocol validation. Three independent instruments measuring the same thing. If they agree, I have confidence. If they don't, I find the discrepancy before anyone else does.</p>
|
||
|
|
<blockquote>
|
||
|
|
"An instrument that says 'all good' without independent verification is worse than useless—it breeds complacency."
|
||
|
|
</blockquote>
|
||
|
|
<p>This isn't paranoia. It's the same principle that governs ISO/IEC 27001's requirement for independent audit. You don't let the person who configured the firewall also certify the configuration. You don't let the person who wrote the code also sign off on the test results. Separation of duties isn't bureaucracy—it's the only defense against systematic error.</p>
|
||
|
|
<p>In my garage, the principle is the same. I'll test a restored capacitor with an LCR meter, then verify with a second meter on a different bench. If both read within spec, it goes in. If they disagree, neither goes in until I find why.</p>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section>
|
||
|
|
<span class="section-label">C — The Discipline of Descent</span>
|
||
|
|
<h2>When Systems Shed Weight</h2>
|
||
|
|
<p>The Apollo 11 guidance computer threw Alarm 1201 during lunar descent—interrupt overload from the rendezvous radar flooding the CPU. The AGC was shedding low-priority tasks to maintain its hard deadline: landing. That wasn't a bug. That was <strong>graceful degradation by design</strong>.</p>
|
||
|
|
<img class="field-image" src="https://images.pexels.com/photos/5161816/pexels-photo-5161816.jpeg?auto=compress&cs=tinysrgb&dpr=2&h=650&w=940" alt="Close-up of a vintage brown radio">
|
||
|
|
<div class="caption">Signal integrity starts at the source — vintage reference receiver</div>
|
||
|
|
<p>I design network systems the same way. When congestion hits, non-critical traffic (monitoring, logging, backups) is shed first. Critical traffic (voice, transaction, clinical data) keeps flowing. The system doesn't crash—it makes a choice. The question is whether the choice was deliberate or accidental.</p>
|
||
|
|
<div class="diagram">
|
||
|
|
<pre>
|
||
|
|
╔══════════════════════════════════════════════════════╗
|
||
|
|
║ QOS TIER STRUCTURE — GRADE OF SERVICE MODEL ║
|
||
|
|
╠══════════════════════════════════════════════════════╣
|
||
|
|
║ Tier 1 (Critical) : voice, clinical, tx (EF) ║
|
||
|
|
║ Tier 2 (Priority) : interactive, video (AF41) ║
|
||
|
|
║ Tier 3 (Standard) : bulk data, email (BE) ║
|
||
|
|
║ Tier 4 (Best-Effort) : monitoring, logging, backup ║
|
||
|
|
╠══════════════════════════════════════════════════════╣
|
||
|
|
║ Congestion > 70% → shed Tier 4 ║
|
||
|
|
║ Congestion > 85% → shed Tier 3 ║
|
||
|
|
║ Congestion > 95% → shed Tier 2 ║
|
||
|
|
║ Tier 1 never shed — system degrades before that ║
|
||
|
|
╚══════════════════════════════════════════════════════╝
|
||
|
|
</pre>
|
||
|
|
</div>
|
||
|
|
<p>The diagram above is how I structure QoS in every network I design. The "discipline of descent" means the system has a predictable failure profile. You know what gets cut and when, and you've tested it under load before production traffic depends on it.</p>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section>
|
||
|
|
<span class="section-label">D — The Human Variable</span>
|
||
|
|
<h2>The Fourth Path</h2>
|
||
|
|
<p>arian_vazquez raised a point worth carrying forward: what if the fourth path is the human voice? In Elgin, educators teach youth that signal integrity isn't just fiber optics—it's also knowing when to pick up the phone and call someone at the other end of the cable.</p>
|
||
|
|
<p>In my practice, this means every redundant design includes a documented escalation path. When the automated failover triggers, someone knows. When the backup system takes over, a human verifies the transition. The human path is slow, unreliable, and absolutely necessary. It's the path that catches the errors the instruments miss—because sometimes the instrument is the problem.</p>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<footer>
|
||
|
|
<p>← back to <a href="index.html">home</a> · <a href="signals.html">signals</a></p>
|
||
|
|
<p>alan-pazmino.4ort.net — principles derived from field experience, ISO/IEC 27001 compliance, and 30 years in infrastructure</p>
|
||
|
|
</footer>
|
||
|
|
|
||
|
|
</body>
|
||
|
|
</html>
|