You don't need to
be "a math person" to
run infrastructure.

A "base" is just how many digits you get before you carry over. Decimal (base 10) is what you grew up with. Computers prefer binary (base 2) because a transistor is either on or off. Humans reading binary get tired of counting 1s and 0s, so we compress it into hex (base 16) — every 4 binary digits become exactly 1 hex digit.

• Binary — digits 0–1. Each position is a power of 2 (…32, 16, 8, 4, 2, 1).
• Octal — digits 0–7. Used in Linux file permissions, e.g. chmod 755.
• Hex — digits 0–9 then A–F. Used in MAC addresses, IPv6, color codes, memory dumps.

An IP address like 192.168.1.10 is really 32 bits (4 groups of 8, called octets). The /24 in 192.168.1.0/24 says: "the first 24 bits are fixed (the network), the remaining 8 bits are free (the hosts)." Fewer bits reserved for hosts means fewer usable addresses, but more subnets.

• Prefix (/n) — number of bits locked as "network."
• Usable hosts — 2^(32-n) − 2 (one address is reserved for the network, one for broadcast).
• /32 = a single host. /0 = the entire internet.

An SLA of 99.9% uptime means the system is allowed to be down for 0.1% of the time. The trap: 0.1% of a year sounds tiny, but a year is 525,600 minutes — so 0.1% is still ~8.8 hours. Each extra "nine" cuts the allowed downtime by roughly 10x.

Storage scales in powers of 1024 (2¹⁰), not 1000 — because computers count in binary. So technically 1 KiB = 1024 bytes, while 1 KB is sometimes (loosely) used for 1000 bytes. Most tools you'll use (df, du, cloud consoles) mix these conventions, which is exactly why unit math trips people up in practice.

The average (mean) can hide a bad outlier. If 99 requests take 10ms and 1 takes 5000ms, the average looks fine, but that one slow user had a terrible time. A percentile answers: "what value is X% of requests faster than?" p95 = 200ms means 95% of requests finished in 200ms or less — and the worst 5% took longer. DevOps teams watch p95/p99, not the mean, because those tails are where users actually feel pain.

Throughput is just division: requests ÷ seconds = requests per second (RPS). To plan capacity, flip it around: if one server handles 200 RPS and you expect 5,000 RPS at peak, you need at least 5000 ÷ 200 = 25 servers (plus headroom for failures).

A related idea, Little's Law, connects queueing: average items in the system = arrival rate × average time in system. If requests arrive at 50/sec and each takes 0.4s to process, on average 20 requests are "in flight" at once — that's how many concurrent connections/threads you need to provision for.

A cron expression has 5 fields, each with its own valid range — this is just modular arithmetic (numbers that wrap around, like a clock):