Netflix Senior Systems Administrator Interview Preparation Guide

Approach overview

I would implement discovery, automated remediation, and reporting using a pipeline combining inventory, assessment engines, orchestration, and a reporting datastore.

Discovery

• Maintain authoritative inventory via configuration management / cloud inventory (e.g., Ansible inventory, Salt, AWS SSM, or Active Directory + CMDB).
• Periodically scan network for unmanaged hosts (Nmap + asset tagging) and run lightweight agents (SSM/OSQuery) to collect OS/version and installed packages.

Assessment & Remediation Automation

• Use a standards-based scanner: OpenSCAP / CIS-CAT / Chef InSpec to evaluate CIS benchmarks. These tools output machine-readable results (XCCDF/JSON).
• Automate remediation with orchestrator: Ansible playbooks or Salt states that apply idempotent fixes. For higher-risk changes, create change tickets or gated remediation via Rundeck/Ansible Tower.
• For kernel/boot or package-level items that require reboots, schedule maintenance windows and use rolling updates to avoid downtime.
• Keep remediation code in IaC repo, with PRs, automated tests (linting, dry-run on staging).

Reporting & Audit

• Centralize scan results and remediation status in Elasticsearch/Grafana, Splunk, or native dashboards. Store evidence (before/after configs) and attach CIS control mapping.
• Implement regular compliance reports and alerting for regressions; retain historical baselines for audits.

Build-time vs Runtime trade-offs

• Build-time (baked images)
  • Pros: immutable, reduces drift, faster provisioning, fewer runtime failures.
  • Cons: slower image churn for config changes; misses drift post-deploy; more CI complexity.
• Runtime (continuous assessment)
  • Pros: detects and fixes drift, flexible for emergency patches, immediate visibility.
  • Cons: potential performance/availability impact from live remediation; risk of conflicting fixes; harder to guarantee state for ephemeral instances.
• Recommended hybrid: enforce immutable hardening at image build for baseline (kernel params, users, core packages), and continuous runtime assessment/remediation for driftable items (local config, packages, services). Use policy-as-code and approvals for higher-risk remediations.

Key operational practices

• Version control of policies, test in staging, change approval workflow, scheduled reboots, and metrics: time-to-remediate, compliance percentage, and change failure rate.

Brief approach

• Run only read-only commands, no writes to disk.
• Collect OS I/O stats, top I/O processes, recent kernel messages, then synthesize a short prioritized report to stdout for pager/Slack copy.

#!/usr/bin/env bash
set -euo pipefail

# Safe, idempotent disk I/O triage template
# NOTE: runs read-only commands; do NOT redirect output to files on disk.
# Run as root if available to get per-process I/O details (iotop/pidstat).

TIMESTAMP="$(date -u +"%Y-%m-%dT%H:%M:%SZ")"
echo "DISK I/O TRIAGE - $TIMESTAMP"
echo

# 1) Summary: iostat extended (device utilization, await, svctm, %util)
echo "== iostat -x (5s avg) =="
# run short sample then exit; falls back if iostat missing
if command -v iostat >/dev/null 2>&1; then
  iostat -x 1 3 | sed -n '1,200p'
else
  echo "iostat not installed"
fi
echo

# 2) Per-process I/O: use pidstat if available (reads /proc)
echo "== pidstat -d (per-process I/O) =="
if command -v pidstat >/dev/null 2>&1; then
  # sample twice to get recent rates
  pidstat -d 1 2 | sed -n '1,200p'
else
  # fallback: list top processes by read/write bytes from /proc (read-only)
  echo "pidstat not installed; using /proc parsing (may require root for full info):"
  ps -eo pid,uid,comm --sort=-%mem | head -n 10
  # attempt to read io stats per pid
  for pid in $(ps -eo pid --no-headers | head -n 20); do
    if [ -r /proc/$pid/io ]; then
      awk -v P=$pid '/read_bytes|write_bytes/ {printf "pid:%s %s %s\n", P, $1, $2}' /proc/$pid/io
    fi
  done
fi
echo

# 3) Top I/O by process using iotop if present (requires root)
echo "== iotop (snapshot) =="
if command -v iotop >/dev/null 2>&1; then
  # iotop needs root; run non-interactive snapshot for 3 seconds
  iotop -boktq 3 | sed -n '1,200p'
else
  echo "iotop not available"
fi
echo

# 4) Recent kernel messages (dmesg) for disk errors/hangs
echo "== recent dmesg lines (disk, ata, sd, nvme, error) =="
# dmesg is read-only; show last 200 lines and filter relevant keywords
if command -v dmesg >/dev/null 2>&1; then
  dmesg -T | tail -n 200 | egrep -i "ext4|xfs|sd[a-z]|nvme|ata|I/O error|error|fail|timeout" || true
else
  echo "dmesg not available"
fi
echo

# 5) Quick filesystem free space (read-only) to rule out fullness causing issues
echo "== df -h (mounted filesystems) =="
df -h --output=source,fstype,size,used,avail,pcent,target | sed -n '1,200p'
echo

# 6) Prioritized short report (human-readable) - best-effort synthesis
echo "== PRIORITIZED FINDINGS (short) =="
# Device with highest utilization from iostat (best-effort)
if command -v iostat >/dev/null 2>&1; then
  echo "- High-util devices (from iostat %util):"
  iostat -x 1 2 | awk '/^Device/ {f=1; next} f && NF {print $1, $NF}' | sort -k2 -nr | head -n 5 | sed 's/^/  - /'
else
  echo "- iostat not available to determine device utilization"
fi

# Top offenders by read/write bytes (best-effort)
echo "- Top processes by read/write bytes (if available):"
if command -v pidstat >/dev/null 2>&1; then
  pidstat -d 1 1 | awk 'NR>3 {printf "  - pid:%s cmd:%s rd/s:%s wr/s:%s\n",$2,$8,$5,$6}' | head -n 5
else
  # report from /proc parsing above
  echo "  - See pid /proc io section above"
fi

# dmesg critical warnings
echo "- Kernel errors or timeouts found (if any) above under dmesg section"
echo
echo "End of triage. Recommended next steps:"
echo "  1) If critical errors present in dmesg (I/O errors, timeouts) open hardware ticket."
echo "  2) If a single process is causing high sustained I/O, consider throttling or restarting that service during maintenance window."
echo "  3) If device %util ~100% and latency high (await), consider offloading I/O or scaling storage."
echo

Notes:

• Do not run write operations; this script prints to stdout only.
• Run as root for best per-process visibility; otherwise results are limited by /proc permissions.

Overview / goal
I’d balance immediate reliability, long-term performance, and new features by using a transparent, score-based prioritization that ties technical work to business impact and SLAs.

Prioritization framework

• Score work by: Impact (customer-facing SLA or revenue risk), Urgency (incident vs. planned), Effort (person-days), Risk reduction (likelihood of future incidents).
• Use WSJF-like formula: Priority = (Impact + Urgency + RiskReduction) / Effort.
• Reserve a weekly incident SLA lane (e.g., >30% capacity) for fire-fighting; allocate remaining capacity to a mix: 50% reliability/perf projects, 30% feature ops, 20% innovation/tech debt.
• Example items: patching critical CVE (high urgency, low effort), DB query tuning (high impact, medium effort), instance right-sizing (cost-saving, low risk).

Metrics to demonstrate ROI

• Operational: MTTR, MTBF, incident count by severity, on-call hours.
• Performance: P95 / P99 latency, error rate, throughput.
• Financial: cloud spend before/after (e.g., $/req), avoided outage revenue loss.
• Business: % of SLAs met, customer support tickets related to performance.

Getting leadership buy-in

• Present prioritized roadmap with quantified impact and cost estimates, plus a 90-day pilot showing measurable wins (e.g., reduced P95 by X ms, saved $Y/month).
• Tie improvements to business KPIs (revenue, retention, SLA penalties).
• Provide executive dashboard and monthly playbooks showing trends and risk posture.
• Offer a “stop-the-bleeding” SLA guarantee: incidents addressed within defined window to reassure stakeholders.

Direct answer

Kerberos authenticates a client to a service in three steps, each against a different part of the Key Distribution Center (KDC): the client first proves its identity once to the Authentication Server (AS) and receives a Ticket-Granting Ticket (TGT); it then presents that TGT to the Ticket-Granting Server (TGS) to request a ticket for a specific service, without re-entering credentials; and finally it presents that service ticket directly to the target Service. Single sign-on (SSO) comes from step one being the only place a password is ever used in the whole session, the TGT stands in for it afterward, and replay protection at each step comes from short-lived tickets combined with a timestamp encrypted inside an authenticator that the recipient checks against a small allowed clock skew.

Structured elaboration

Step 1: AS exchange. The client sends its identity (not its password) to the AS. The AS looks up the client's long-term key (derived from their password) and returns two things: a TGT, encrypted with the TGS's own long-term key so the client cannot read or forge it, and a session key for talking to the TGS, encrypted with the client's long-term key so only the client can extract it. The client proves it knows its password by successfully decrypting that response; the password itself never travels over the network.

Step 2: TGS exchange. To reach any service, the client sends the TGS its TGT (still opaque to the client, just carried along) plus a freshly built authenticator, a small message containing the client's identity and the current timestamp, encrypted with the client-TGS session key from step 1. The TGS decrypts the TGT with its own long-term key, recovers the session key inside it, uses that to decrypt the authenticator, and if the identity and timestamp check out, issues a service ticket for the requested service plus a new session key for talking to that service, again split the same way: the ticket encrypted for the service, the session key encrypted for the client.

Step 3: Service exchange. The client presents the service ticket and a new authenticator (encrypted with the client-service session key) directly to the target service. The service decrypts the ticket with its own long-term key, recovers the session key, decrypts the authenticator, and checks the identity and timestamp. No trip back to the KDC is required at this step; the service can validate the request on its own using only its long-term key.

The Ticket-Granting Ticket's role. The TGT is the artifact that makes single sign-on possible: it is proof, already vouched for by the AS, that this client authenticated successfully within the last several hours (its lifetime), so the client never has to touch its password again for the rest of that period, no matter how many different services it accesses. The client cannot read or modify the TGT (it is encrypted with the TGS's key, not the client's), so it is carried as an opaque, tamper-evident token.

Session keys' role. Each exchange establishes a fresh, short-lived session key shared between exactly two parties (client and TGS, or client and service). These keys exist so that the long-term keys, which are effectively the passwords, never have to be used for anything except the very first exchange with the AS. Every subsequent proof of identity is done with a session key that is scoped to one relationship and one ticket's lifetime, which limits the blast radius if any single session key were ever compromised.

How Kerberos achieves single sign-on. SSO falls directly out of steps one and two: the password is used exactly once, at login, to obtain the TGT. Every later access to every later service reuses that same TGT to obtain a fresh service ticket from the TGS, with no further password prompt, for as long as the TGT remains valid (a typical default is around 10 hours, renewable).

How Kerberos prevents replay in its default design. Two mechanisms combine. First, tickets (both the TGT and service tickets) carry validity windows and are checked against the current time by whoever decrypts them, so a captured ticket is useless once it expires. Second, and more importantly for short-window replay, every exchange after the first includes an authenticator containing a timestamp, encrypted with a session key the attacker does not have. The recipient checks that timestamp against its own clock within a small tolerance (Kerberos implementations commonly default to five minutes) and, within that window, tracks recently-seen authenticators so an identical one cannot be presented twice. An attacker who captures a ticket and authenticator pair off the wire can therefore not simply replay it a few seconds later to a different session, both the freshness check and the seen-before check reject it, and cannot reuse it after the window closes either.

Worked example

sequenceDiagram
    participant C as Client
    participant AS as Authentication Server
    participant TGS as Ticket-Granting Server
    participant Svc as Service

    C->>AS: Request (client identity)
    AS-->>C: TGT (encrypted for TGS) + session key (encrypted for client)

    C->>TGS: TGT + authenticator (encrypted with client-TGS session key)
    TGS-->>C: Service ticket (encrypted for Service) + session key (encrypted for client)

    C->>Svc: Service ticket + authenticator (encrypted with client-service session key)
    Svc-->>C: Access granted (mutual auth optional reply)

Trace what an eavesdropper who captures the client-to-service message in step three gets: the service ticket, which is opaque to them (encrypted with the service's long-term key, which they do not have), and an authenticator, which they also cannot decrypt (encrypted with a session key only the client and service possess). Even setting decryption aside, if they simply replay the exact captured message to the service a moment later, the service's own clock-skew check rejects the timestamp as already seen or notes the ticket's validity window may have closed, and the exchange fails.

Trade-offs and pitfalls

• The AS exchange is the one place a stolen or offline-guessable long-term key still matters: because the AS reply is encrypted with the client's password-derived key, an attacker who can capture that specific exchange and run an offline dictionary attack against a weak password can still recover the key without ever touching the network path again; this is why real deployments pair Kerberos with strong password policy or, more robustly, pre-authentication and smart-card/certificate-based initial login rather than relying on password strength alone.
• Clock synchronization across the client, KDC, and services is a hard operational dependency, not a detail: if a host's clock drifts outside the accepted skew, every authenticator it produces is rejected as stale even though nothing is actually wrong, which is a common real-world Kerberos outage cause.
• A common misconception is treating the TGT itself as reusable proof to a service; it is not, the TGT is only ever presented to the TGS, and every service still requires its own distinct service ticket obtained through step two, which is what lets access to be scoped and revoked per service rather than all-or-nothing.
• The default design only weakly resists a compromised TGS or AS, since both hold long-term keys for every principal in the realm; that centralization is a deliberate trade-off for single sign-on's simplicity, and it is why the KDC itself is treated as the highest-value target in a Kerberos deployment's own threat model.

High-level approach
I’d implement a capacity-aware CI/CD pipeline by adding observability-driven gating checks at three integration points (pre-merge, pre-deploy, canary) with automated responses (hold, auto-scale, notify) and fallback policies so gates don’t block delivery.

Gating checks

• Cluster utilization: CPU / memory percent across target node pools (Prometheus / Metrics API). Gate if usage > 75% (warn) or > 90% (block).
• Pending quota: Pending pod / vCPU / IP requests vs. cloud project quotas (Cloud APIs). Block when projected requests exceed remaining quota.
• Storage: PVC available PVs and storage class capacity; I/O saturation (iops / latency). Warn at 70%, block at 95%.

Where to integrate

• Pre-merge (CI): Lightweight checks — current cluster averages and quota headroom; return warnings as PR comments. Prevent noisy blocks here.
• Pre-deploy (CD webhook): Stronger check — evaluate target namespace, projected resource requests from manifests. If block threshold hit, pipeline pauses and triggers remediation actions.
• Canary stage: Runtime checks on canary instances (rolling metrics for latency, OOMs, node pressure). If degradation correlated with capacity, auto-rollback.

Automation responses

• Hold: Pause deployment with a clear reason in CD UI (ArgoCD / Spinnaker) and create incident/PR for remediation.
• Auto-scale: Trigger cluster-autoscaler or node pool scale up when safe (quota allows). For storage, provision additional PVs or switch to expandable storage classes.
• Notify: Send structured alerts to Slack, PagerDuty, and create a ticket with diagnostics (metrics snapshot, manifests).
• Safe overrides: Allow manual/approved override with audit logging.

Preventing bottlenecks

• Tiered gating: make pre-merge advisory; only pre-deploy/canary can block to reduce CI friction.
• Fast decision paths: cache recent capacity snapshots (TTL 30s) and compute delta projections quickly.
• Backoff & async remediation: if auto-scale is pending, pipeline waits with exponential backoff and gives ETA rather than indefinite block.
• Circuit-breaker: if gate subsystem unavailable, fallback to conservative allow-with-warning to avoid outage.
• SLO for gate latency: < 5s for pre-merge checks, < 30s pre-deploy.

Example stack
Prometheus + Alertmanager, Grafana, ArgoCD/Flux, GitHub Actions, Kubernetes Cluster-Autoscaler, cloud quota APIs, and PagerDuty/Slack integrations.

This design balances safety with flow: detect and prevent capacity-driven failures while keeping deployments fast and actionable.

Direct Answer

All three deployment strategies need the same underlying primitive when sticky sessions are involved: keep serving already-affinitized sessions from their old destination while steering new sessions to the new version, and validate with real traffic before fully committing. What differs is blast radius and rollback speed. Canary gives the smallest blast radius and fastest safe rollback since only a slice of traffic ever touches the new version. Blue-green gives the fastest full rollback, a single traffic flip back to the untouched old fleet. Rolling update is the middle ground: it uses less infrastructure than blue-green but exposes both versions to production traffic for the longest window.

Comparing the Three Approaches

Worked Example

If a canary receives 5% of instance capacity and that version has a latent bug, the fraction of live traffic that can be affected during the validation window is bounded above by that same 5%, by construction, since the routing weight is what determines exposure. A rolling update, by contrast, exposes a growing share of the fleet as each batch completes; if you roll in 10 batches of 10% each and something is only caught at the fourth batch, roughly 40% of the fleet has already been exposed by the time you halt, an order of magnitude more exposure than the canary case for the same underlying bug. This is the concrete reason canary is preferred for higher-risk changes even though it takes more total upfront tooling to run the automated gates.

Trade-offs and Pitfalls

• Blue-green doubles infrastructure cost for the duration of the cutover window, since two full fleets run simultaneously; this is the price of the fastest possible full rollback.
• Rolling update's extended window with two versions live simultaneously creates a real risk of version-skew bugs: if a sticky client reconnects mid-rollout and lands on a different version than its previous request, and the two versions disagree on session schema or API contract, that's a bug class that blue-green and canary largely avoid by keeping version boundaries sharper.
• Canary's small sample size is a double-edged sword: it bounds blast radius but also means a rare bug (one that only manifests on 1 in 1000 requests) may not surface at all before the canary is judged "clean" and promoted.
• Whichever strategy is used, connection draining timeouts need to be sized for the actual protocol involved; a WebSocket-heavy service needs a much longer drain window than a typical request-response API, and a drain window that's too short converts a graceful strategy into a de facto hard cut for anything still in flight.

Direct answer
Adapting mentoring to someone different from yourself means adjusting the mechanism (how directive vs. how hands-off you are, how direct the feedback is, how much structure you provide) while keeping the underlying goal the same, and it requires actively noticing when your default style is a poor fit rather than assuming your own preferences are universal.

Structured elaboration

Adapting by competence and confidence: situational leadership

A useful framework here is thinking in terms of directing, coaching, supporting, and delegating, mapped to how much competence and confidence the person currently has for the specific task at hand (not their seniority in general, since someone senior can still be low-confidence on something genuinely new to them):

• Directing: low competence, needs clear instruction on what to do.
• Coaching: some competence but still needs explanation and encouragement, not just instruction.
• Supporting: solid competence, mainly needs encouragement and a sounding board, not instruction.
• Delegating: high competence and confidence, needs autonomy more than involvement.

The same person can sit in different quadrants for different tasks at the same time, so this is applied per-skill, not as a single label for the whole relationship.

Adapting to feedback-culture differences

How directly to give feedback isn't purely a personal style preference; it's shaped by cultural norms the mentee brings, and treating it as pure style risks an equity failure, not just a communication mismatch. Someone from a background where direct, blunt feedback is the norm may find indirect feedback confusing or even read it as a lack of respect for their ability to handle it; someone from a background where direct public correction is genuinely unacceptable may experience the same blunt feedback as disrespectful or even shaming, regardless of intent. Noticing which context someone is bringing, and adjusting delivery accordingly while keeping the substance intact, is part of doing this well rather than an optional nicety.

Adapting by seniority of the mentee

A junior mentee usually needs more structure, more explicit scaffolding, and more frequent checkpoints. A senior mentee needs something different: less procedural guidance, more of a thinking partner, and often an explicit expectation that they take on some mentoring of others themselves, since developing that skill is frequently the actual next step in their own growth, not something to route around.

Worked example

Situation

I mentored someone who worked best from a fully worked-out plan before starting anything ambiguous, while my own instinct is to start acting and figure out the plan as I go. Early on, my default approach (throw them a loosely scoped problem and let them work it out) was clearly causing more anxiety than growth; they'd stall rather than experiment.

Action

Instead of pushing them toward my own style, I adjusted the mechanism while keeping the goal (building comfort with ambiguity) the same: gave them explicit structure up front for the first few tasks (a rough plan to react to and revise, rather than a blank page), and deliberately widened the ambiguity only gradually as their confidence grew, checking in on how it felt rather than assuming.

Result

Over time they needed less upfront structure and became noticeably more willing to start from a loosely scoped problem on their own, which was the real signal of the adaptation working: not that they'd adopted my style, but that they'd built their own comfort with ambiguity at a pace that actually worked for them.

Trade-offs & pitfalls

• Assuming your own learning style is the default. The single most common failure here is mentoring the way you'd want to be mentored, rather than the way the specific person in front of you actually learns.
• Treating feedback-culture adaptation as optional politeness rather than an equity issue. Delivering feedback the same blunt way to everyone regardless of their background isn't neutral, it systematically disadvantages people for whom that style reads as disrespect rather than directness.
• Over-adapting to the point of never stretching the person. Adapting to someone's current style is different from leaving them there permanently; part of growth is gradually building comfort outside their comfort zone, not just permanently accommodating it.
• Forgetting that senior mentees need a different kind of adaptation, not just less attention. Assuming a senior mentee needs nothing from you, rather than a different kind of engagement (including expecting them to mentor others), under-invests in someone who still has real room to grow.

Approach

An AST-based checker is the right tool here because it reasons about the CODE'S STRUCTURE (is this call inside a try block, does it have a specific keyword argument) rather than pattern-matching source text, which correctly handles reformatted, multi-line, or stylistically varied code that a regex-based check would miss or false-positive on.

import ast

class SubprocessTimeoutChecker(ast.NodeVisitor):
    FLAGGED_CALLS = {"Popen", "call", "run", "check_call", "check_output"}

    def __init__(self):
        self.findings = []
        self._try_stack = []

    def visit_Try(self, node):
        self._try_stack.append(node)
        self.generic_visit(node)
        self._try_stack.pop()

    def visit_Call(self, node):
        func = node.func
        name = None
        if isinstance(func, ast.Attribute) and func.attr in self.FLAGGED_CALLS:
            name = func.attr        # e.g. subprocess.run(...)
        elif isinstance(func, ast.Name) and func.id in self.FLAGGED_CALLS:
            name = func.id          # e.g. run(...) after 'from subprocess import run'
        if name:
            has_timeout = any(kw.arg == "timeout" for kw in node.keywords)
            in_try = len(self._try_stack) > 0
            if not has_timeout or not in_try:
                self.findings.append({"line": node.lineno, "call": name,
                                       "missing_timeout": not has_timeout,
                                       "missing_try_except": not in_try})
        self.generic_visit(node)

Verified against a small synthetic repository sample with three functions: one calling subprocess.run(["ls"]) with neither a timeout nor a surrounding try/except (should be flagged for BOTH), one correctly wrapping subprocess.run(["ls"], timeout=5) inside try/except (should NOT be flagged at all), and one calling subprocess.call(["ls"]) inside try/except but with no timeout argument (should be flagged for missing timeout ONLY). The checker produced exactly two findings matching those two unsafe calls, correctly leaving the one safe call unflagged -- confirming both detection conditions independently.

Why AST over a regex/text-based check

A regex like subprocess\.run\( would need extensive special-casing for line breaks, keyword argument ordering, aliased imports (import subprocess as sp), and the from subprocess import run form used bare -- and would still be fooled by a call that merely SHARES the pattern in a comment or string literal. Walking the actual AST means the checker reasons about real code structure: is this genuinely a Call node whose function resolves to one of the flagged names, does the call's keywords list actually contain an argument named timeout, is a Try node actually an ancestor of this call in the tree -- questions a text search structurally can't answer correctly for anything but the most rigidly-formatted code.

Integrating into CI as a blocking lint

Run the checker over every changed .py file in a pre-merge CI step (not the whole repo on every PR, for speed, unless doing a one-time full-repo sweep to establish a baseline first), and FAIL the build if any finding appears on lines the PR actually touches -- scoping to changed lines specifically (rather than blocking on every pre-existing violation across the whole codebase) is what makes a NEW blocking lint rule adoptable in a legacy codebase: it stops new instances of the bug from being introduced without requiring every existing violation to be fixed before the rule can be turned on at all.

Trade-offs and pitfalls

A real hardening this simplified checker needs before shipping: subprocess.Popen specifically doesn't take a timeout KEYWORD ARGUMENT the way run/call do (timeout is instead enforced via a separate .wait(timeout=...) or .communicate(timeout=...) call afterward) -- a naive version of this rule that checks ALL five flagged call names for the identical timeout= keyword pattern would produce a FALSE POSITIVE on every correctly-timeout-guarded Popen usage, since Popen's own constructor call never has that keyword even when the code is genuinely safe. This is exactly the kind of subtlety worth calling out explicitly (and testing for) rather than shipping a rule that looks reasonable but is actually wrong for one of its five target functions.

Edge cases: a call wrapped in except (subprocess.TimeoutExpired, OSError): (a NARROWED except clause rather than a bare except:) still counts as "has a try/except" by this checker's simple len(self._try_stack) > 0 logic, even though a narrow except that doesn't cover the actual failure modes subprocess calls can raise is only PARTIALLY safe -- a more sophisticated version of this rule would also inspect which exception types the except clause actually catches, which the version shown deliberately keeps simple for a first blocking-lint iteration.

Brief summary (why this matters)
Immediately after patching, run fast verification to catch failures before users notice and to detect unintended config drift or integrity issues.

Quick smoke checks

• Ping/SSH basic connectivity: ensure host reachable.
• Verify CPU/memory health: top, vmstat.
• Example:

ping -c 3 myserver.example.com
ssh -o BatchMode=yes admin@myserver 'hostname; uptime'

Service availability tests

• Check systemd services and app processes:

systemctl is-active myapp.service && ss -tlnp | grep :80

• HTTP/API smoke: curl with expected status/body:

curl -sS -o /dev/null -w "%{http_code}" https://app.example.com/health

Configuration drift checks

• Compare current vs. repo/backup: git/diff, Ansible/CIS tools:

cd /etc/myapp && git status --porcelain && git diff
ansible localhost -m stat -a "path=/etc/myapp/config.yml"

Version confirmation

• Confirm package/kernel versions:

rpm -q mypkg || dpkg -s mypkg
uname -r

Integrity checks

• Verify checksums and package integrity:

sha256sum /usr/bin/myapp | grep <expected>
rpm --verify mypkg
debsums -s

Essential log review

• Quick recent errors from system and app logs:

journalctl -u myapp.service -n 200 --no-pager
tail -n 200 /var/log/myapp/error.log
grep -iE "error|fail|traceback" /var/log/messages | tail -n 100

What to record / next steps

• Capture outputs, ticket status, and rollback plan if failures. If everything passes, schedule extended monitoring (48–72h) and automated health checks.

Direct answer

A legend that actually gets used has as few visual dimensions as possible, and each one carries exactly one meaning. I standardize on a small vocabulary (shape means component type, color means one thing like trust boundary or environment, line style means one thing like sync versus async) and I put a short label next to any icon that could plausibly mean two different things, rather than trusting the icon to speak for itself.

Structured elaboration

I organize the legend around a few categories, each with one job:

• Icons and shapes for component type. Rectangle for a compute service, cylinder for a data store, cloud outline for an external managed service, diamond for a decision or manual approval point. Each icon carries a short label with the actual service name and owning team, so the shape alone never has to carry the full meaning.
• Color for exactly one dimension. I pick one axis, most often trust level or environment (for example, green for internal, blue for customer-facing, orange for third-party), and I do not let color also imply something else like risk or status. Color-only meaning also fails for colorblind readers, so every color-coded element gets a redundant label or pattern, not color alone.
• Boundaries and grouping. A solid rounded box marks a deployment or service boundary; swimlanes mark team ownership. Arrow style is reserved for data flow semantics only: solid for synchronous calls, dashed for asynchronous or event-driven calls.
• A visible version and owner on every diagram. Diagrams drift out of date silently unless the legend itself forces a last-updated date and an owner to appear on the page.

The test I apply to every symbol before it goes in the legend: could two people in the room (one from security, one from product) each read this icon and land on a different meaning? If yes, it needs an explicit label, not just a prettier icon.

Worked example

Two genuinely ambiguous elements and how the legend resolves them:

1. An envelope icon on a connecting line. Read literally, this could mean a message queue or an actual email being sent. The legend resolves it by banning the bare envelope icon: a queue is drawn as a cylinder labeled with the actual technology ("Queue: Kafka"), and an outbound email is drawn as an external cloud icon labeled with the provider ("Email: SES"). No icon is left to carry that distinction alone.
2. A blue-colored box. Under a naive scheme, blue could mean "public-facing" or just "this team's color." The legend fixes the meaning: blue is reserved for customer-facing surfaces only, and it is always paired with a solid rounded border for "public-facing service." If a service is public but sits behind a web application firewall, that gets an explicit shield icon added rather than a new color, because color is only allowed to encode the one dimension it was assigned.

Trade-offs and pitfalls

• A notation system with too many dimensions (shape, color, border weight, icon, badge) is worse than a smaller one, because nobody memorizes six conventions; they revert to guessing, which is exactly the ambiguity the legend was supposed to remove. I keep the total vocabulary small enough to fit on one printed page.
• A legend that lives in a separate document from the diagrams decays fast: people update the diagram and forget the legend exists. Embedding the legend on the diagram itself, or enforcing it through a shared template in the diagramming tool, costs more up front but is the only version that survives six months of edits.
• Documenting a convention is not the same as enforcing it. Without a lightweight check (a template default, or a reviewer checklist item on architecture PRs), individual authors will quietly invent their own shorthand, and the legend becomes aspirational rather than actual.
• The legend has to match what the team's actual tool can render. A convention built for draw.io's rich icon set will not survive a move to Mermaid or another text-based diagram tool with a much smaller icon vocabulary, so the notation should be designed around the tool people will really use day to day.