Millise NetworkManageri oleku teie teavitaja tegelikult sai?

Olek neli käivitab ühes API-s teate ja tähendab teises midagi muud, ning kood ei näita üldse mingit erinevust. Iga olekuväärtus NetworkManageris kuulub nimega loendisse ja loendid ei ole ühel meelel, mida antud arv tähendab. Seetõttu ei ole täisarvu kopeerimine töötavast katkendist teise tagasikutseusse ülekandmine; see on kokkusattumus, mis ootab purunemist. Leidke esmalt tüüp ja arv muutub loetavaks.

Number ilma tüübita on vaid kuulujutt

Siin on olulised kaks loendit. Üks kirjeldab aktiivset ühendust üldiselt: tundmatu, aktiveeriv, aktiveeritud, deaktiveeriv, deaktiveeritud. Teine kirjeldab spetsiaalselt VPN-ühendust ja sellel on teel rohkem peatusi, sealhulgas ettevalmistus, ühenduse seadistamine, IP-konfiguratsioon ja autentimispäring enne, kui midagi aktiveeritakse. Nende nummerdamine algab mõlemal juhul nullist ja lahkneb seejärel, nii et üldises loendis deaktiveeritut tähendav väärtus maandub kuskil VPN-jada keskel. Kumbki päis ei ole vale; nad vastavad erinevatele küsimustele.

Kasutage paigaldatud päisest või sidumisest pärinevat sümboolset konstanti, mitte literaali. Nimi peab vastu ümbernumerdamisele; täisarv mitte.

Jälgige üht ühendust, mitte masinat

Alustage profiili UUID-st, mis teid huvitab, ja selle aktiveerimise loodud aktiivse ühenduse objektist. Seadme olek või teise tunneli olek ei ole asendus, isegi kui mõlemad muutuvad samal hetkel. Hoidke objekti identiteet koos vaatlusega, et hilisem aruanne saaks öelda, milline profiil selle tekitas. Masinal on palju olekuid; teade käib ühe kohta neist.

Seejärel otsustage, mida teade peaks tähendama. Ühendus, mis ei jõudnud kunagi aktiveerimiseni, on seadistamise tõrge, ja sessioon, mis oli aktiivne ja seejärel kadus, on kaotus. Need väärivad erinevaid sõnu.

Öelge, millist üleminekut te teatate

Salvestage eelmine olek ja võrrelge seda uuega, selle asemel et uut väärtust isoleeritult testida. Üleminek ebaõnnestunud olekusse ja üleminek aktiveeritud olekust välja on erinevad sündmused, isegi kui mõlemad lõpevad ilma millegi ühendatuna. Märkige kõrvale põhjuse string, sest sageli on see ainus osa, mille alusel kasutaja saab tegutseda.

Tahtlik lahtiühendamine ei ole rike. Kui teade ei suuda vahet teha, õpetab see inimesi seda ignoreerima.

Hoidke vaatleja elus

Korduv küsitlemine ei tohi tõstatada veel üht hoiatust oleku kohta, mis ei ole muutunud. See üks reegel eemaldab suurema osa mürast, mida need teavitajad tekitavad.

Käsitlege ka juhtu, kui haldur taaskäivitub või vaadeldav objekt asendatakse. Aegunud identiteediga seotud vaatleja vaikib täpselt hetkel, mil juhtub midagi huvitavat, ja vaikus näeb välja nagu tervis. Avastage praegune objekt uuesti pärast halduri kohaloleku muutust ja märkige, millal uuesti avastamine toimus. Vastasel juhul näitab logi tunnelit, mis lihtsalt lõpetas raporteerimise.

Toimetage teade sinna, kus on kasutaja

Privilegeeritud süsteemi tagasikutse ei päri töölaua sessiooni teavitusteenust. Juurkasutaja tasemel töötlejast saadetud sõnum võib kaduda ilma veata, mis annab teavitaja, mis töötab käsitsi testides ja mitte kunagi praktikas. Toimetage teade sessiooni, mis omab töölauda, või laske töölaua enda kliendil teade esile kutsuda.

Eelistage kliendi olemasolevat teavitust, kui see juba juhtumit katab, sest kaks teavitajat ühe sündmuse kohta on tugiprobleem, mitte liiasus. Hoidke sündmuse aeg, profiil ja põhjus tugikirjes ning jätke paroolid ja täielikud profiilid sellest välja. Pidage meeles, mis teade on: vaadeldud oleku aruanne, mitte jõustamismehhanism, sest liikluse blokeerimine tunneli puudumisel on eraldi poliitika oma rakendusega.