Första riktiga lärdomen: en radioström är ett långtidstest, inte ett demo.
När den första MP3-strömmen fungerade kom nästa period: att få den att fortsätta fungera. Det här låter mindre spännande än senare AI- och showproblem, men flera av de viktigaste driftvanorna kommer härifrån.
Jag började se skillnaden mellan ett fel som stoppar allt och ett fel som bara gör upplevelsen sämre. Ett streamavbrott är uppenbart. Fel metadata är mer förrädiskt eftersom ljudet fortsätter samtidigt som informationen runt radion börjar ljuga. Ett problem med återanslutning kan ligga dolt tills en komponent behöver startas om. En långsam fil kan fungera nittionio gånger och stanna den hundrade.
Det gjorde att jag började tänka i watchdogs, health checks och återhämtning långt innan de funktionerna fick fina namn. Om en del kan dö måste någon annan kunna upptäcka det. Om en tjänst måste startas om ska resten helst fortsätta. Om state måste sparas ska det göras innan processen försvinner.
Jag byggde inte allt detta 2020 på en gång. Det växte fram genom att samma typ av driftfel återkom i olika former. Varje liten fix blev en ledtråd till hur nästa generation borde se ut.
Det var här jag slutade tänka “starta radion” och började tänka “driva radion”. Det är två helt olika problem.
Det tråkiga jobbet som senare blev guld
Jag började föra enklare anteckningar om när något stannade och vad som hänt precis innan. Det var inte avancerad observability, men det lärde mig att tidsstämplar är värdefulla. “Det dog någon gång i natt” hjälper nästan inte alls. “Källan tappade kontakt 02:14:07 och försökte återansluta 02:14:12” går att arbeta med.
Jag började också skilja på process up och service healthy. En process kan leva men vara oanvändbar. Den kan ha en öppen port men inte leverera ljud. Den idén återkommer idag i Westin-AI och Kontrollcenter där health inte bara betyder att processen finns.
Jag byggde mina första mentala health checks innan jag hade riktiga health endpoints
I början bestod kontrollen ofta av ganska manuella frågor. Hör jag ljud? Byter låtnamnet? Går det att ansluta igen efter att spelaren stoppats? Fortsätter servern efter en omstart? Det var enkelt, men det lärde mig att “processen kör” är ett dåligt mått på om en radiotjänst är frisk.
En process kan leva men sitta fast. En port kan svara men skicka gammal data. En ljudkälla kan vara ansluten utan att faktiskt mata frames. Därför började jag tänka i flera nivåer av hälsa: process, anslutning, dataflöde och faktisk output.
Den tanken har senare blivit mycket konkret i tjänsterna. Westin-AI behöver inte bara säga att processen lever; Kontrollcenter behöver veta om modellen är redo att rendera. Now Playing behöver inte bara svara HTTP; svaret ska ha färsk metadata. Broadcast kan vara uppe, men om ljudkön inte rör sig är något ändå fel.
Jag började också inse att loggar måste berätta mer än “error”. Ett fel som bara säger att något gick snett tvingar mig att återskapa problemet. Ett fel som säger vilken del, när, med vilket state och vilken fallback som valdes blir dokumentation i realtid.