Tricks of the trade 101 / Kulmakarvoilla ei ole mitään tekemistä näkemisen kanssa

Tricks of the trade 101

05/20/14
tarinat / teknologia

lataus

Johtuen mm. NDA-sidonnaisista syistä en voi porautua näiden issuiden ja kipupisteiden tarkempaan analyysiin. Kirjailen ne vain ylös tähän julkiseen Notepadiini, ehkä koet ne hyödykkäiksi tai sitten et.

Olen pannut merkille, että erityisesti suomalaisilla on pahana tapana mussuttaa mm. huonosta ohjelmasta televisiossa tai suppeasta radion soittolistasta ..vaikka lopulta töllön saa kiinni ja autoonkin voi rigata interwebsiradion tuomaan kivaa variaatiota ajomatkoihin. Tahtonen sanoa tällä kuivakkaan anekdootinpalasella, että se kurjuus on aivan user actioneista kiinni tai lack of them.

Otetaan hypoteettinen tilanne, jossa vastuullasi on about 15k käyttäjän monitahoinen infra, joka pöhisee pääsääntöisesti Microsoftvetoisesti eteenpäin. On intranettiä, extranettiä ja out-of-bound etäduunareita; kaikki sulassa sovussa ja iskettynä samaa Active Directoryyn jossa n-määrä domain controllereita, n+1 aliverkkoa ja n+2 liittymää. Aloitetaan tämä aivan alusta.

Lucky you! Pääset vetämään nk. suuria linjoja aivan alkutekijöissä olevaan domainiin. Ekat jutut ekoina, mieti tarkoin master datasi ja mitä kenttiä siihen tulee; yleensä palkanmaksusysteemeistä saa hyvän pohjan, mutta älä kuitenkaan käytä samaa kantaa omaan master dataasi. Haluat kuitenkin, että oma osastosi omistaa tiedon eikä joku kansakoulutettu vaihdevuotinen jehu palkkiksessa. Eli saat skaalata sitä myöhemmin mitenkuten pystyt tai osaat.
Perusjuttuihin ..vältä nimeen sidonnaisia tunnisteita käyttäjällä, tulevaisuudessa on paljon notkeampaa lyödä vain aliaksia sähköpostijärjestelmään sen ua3563 -käyttäjän alle kun esmes avioliitot ja erot muuttavat ihmisten nimiä. Tunnisteeseen kannattaa varata skaalautuvuutta aina siihen pariin miljardiin pitäen kuitenkin tietyn loogisuuden, siten että ihmissilmä voi tarvittaessa poimia esmes oikeat tunnukset oikeisiin OU:hin. Vaikka nyt palkkiksen tyypit ois pr(payroll) -alkuisia rd ois tutkimuksen etc. Älä vedä master dataa kuitenkaan niin lukkoon etteikö siihen pystyisi tulevaisuudessa lisäämään uusia metakenttiä kuvailemaan ihmisten rooleja jne. Kaikkea et voi future prooffata, mutta design guidelinet voit kirjailla valmiiksi.

Yay! Domaini on pystyssä ja ihmiset pääsevat jopa kirjautumaan siihen. Pääset pähkäilemään tietoturvan kanssa eli ketä saa päästä ja mihin. Nokkelana IT-olmina vihellät pelit poikki ja heität pallon muille osastoille, joihin jalkautetaan käytäntö käyttöoikeusvastaavista, joilla varahenkilöt. Näiden peebsien tehtävänä on vahvasti autentikoida kenen pitää päästä oikeasti ja minne ..yleensä naamatusten. IT-osaston tehtävänä ei ole polisoida tai sotkeutua intrapersoonallisiin riitoihin; IT toimittaa vain vempeleet millä hommat luistaa.
Poikkeuksena tähän tietenkin normituotantoa haittaavat väärinkäytökset ja infraa uhkaavat ulkoiset tekijät. Nämä em. issuet hyvinkin paljon ITeen vastuulla. No palataan näihin luomakunnan kruunuihin eli käyttöoikeusvastaaviin, heillä on käytössä hallintaliittymä, josta voivat sallia tai evätä eri tasoista accessia osaston resursseihin. Miksi näin? IT ei voi millään olla isossa organisaatiossa 100% kartalla kuka on talossa, kuka ei ja mihin kenenkin lopulta pitäisi kuulua tai ei kuulua, kuten sanottu vempeleet ja taika tulee ATK-jäbiltä, käyttämisen vastuu ..no käyttäjiltä. Audittitrailit näkyy kuitenkin kuuhun asti kuka on hyväksynyt ja mitä oikeuksien osalta.
Älä lähde toimimaan HR-natsina, mutta huomauta kohteliaasti, että kyllä ne lokitkin päätyy tarvittaessa viranomaisten huomaan sikäli jos pyyntö on tullut oikealta taholta JA oikein esitettynä. Parempi on ettet myöskään spekuloi tai ekstrapoloi hallussasi olevan tiedon kanssa. Ilmoitusmuotona on tämä käyttäjä, työasemasta, kellonaika se ja se palvelussa se, jonka jälkeen porteissa XY oli liikennettä Z.

Olethan muistanut kirjata kaikki ylös formaalille dokumenttipohjalle, josta ilmenee tarkastajat ja hyväksyjät?

Hommat rullaa ja bisnes laajenee. Olethan miettinyt extranettijärjestelyt omalle firmallesi, you know sellaisen minkä kanssa voi jakaa digitaalista matskua vaikka nyt sidosryhmien kanssa. Nimittäin sähköposti on maailman paskin media tähän, monestakin syystä. Ihan ekaksi se romuttaa kaiken toiveen tehokkaasta versiohallinnasta, jokainen viestin saaja omistaa mailin jälkeen oman kappaleensa dokusta ja jos ei ole tarkkana headereiden versionumeroiden ja päiväysten(nämä on tärkeitä myös) niin damagea syntyy.
Optimaalisessa tilanteessa olisi vain yksi repositoria dokumenteille mitä sitten sorkitaan versiorakenteissa, kaikki viittaukset dokumenttiin olisi relatiivisen linkin kautta johon voi sallia pääsyn myös ulkomaailmasta, jos dokkarin authori sellaista toivoo. Samaan roskaan integroit nasevasti hyväksymis- ja kommentointikierrokset.
Kaikki oman puljunkaan jätkät ei halua aina auringon kivasti paistaessa tulla töihin, joten joudut miettimään miten näiden sankareiden kättely salaiseen infraan suoritetaan ..oli sitten citrixit tahi vpännät se weapon of choice. Kannattaa kuitenkin pitää mielessä, että jokainen lisätty tietoturvalayeri vähentää systeemin käytetävyyttä aina siihen pisteeseen asti, että tuotteesta muodostuu mahdoton käyttää. Tietojärjestelmien yksi keskeisimmistä elementeistä on se, että layer kasi pystyy oikeasti käyttämään niitä. Pankit suosivat automaateilla nk. “vahvaa” autentikaatiota, eli käyttäjä kätellään sisään tiedoilla, jotka sisältävä 1jotain mitä hän tietää ja 2jotain mitä hänellä on, jos järjestely riittää rahamaailmalle niin kyllä se silloin riittää myös sinunkin konepajallesi.

Älä hypistele IT-härveleitä hypistelemisen riemusta tai versiohuoraamisen vuoksi. Odota rauhassa, että kaavailemaasi härveliin on julkaistu eka servicepack tai sitä hetkeä, että Technetissä on enemmänkin kuin yksi artikkeli systeemistä. Future prooffaus on IT:ssä käytännössä mahdotonta, joten älä hötkyile, ydinvoimaloita ohjataan vieläkin täysin merkkipohjaisten järjestelmien avulla. Nykyinen trendi early accessien ja beta testing asiakkaan rahalla/ajalla on niin yleistä, että kannattaa mielummin jonkun toisen hyväuskoisen hölmön suorittaa se. Jos jokin toimii ja ei hypi silmille niin miksi vaivautua? Odota mielummin asiakaskeissejä ja niistä lohkaistavia projekteja. Mikkisen tuotteilla on kuiten sellainen feature, kuin EoL eli tuki ja patchit loppuvat niihin joskus tulevaisuudessa ..listen and take heed.

Varaudu enterprise levelin kriiseihin ennakolta vaatimalla mm. hyväksymiskierroksia ja huoltoikkunoiden kunnioittamista. Optimaalisin tilanne on, että kaikki liveen vedettävät jutut on yhden ihmisiä vihaavan adminin takana; muut asiantuntijat saisivat mellastaa proof of conceptiensa kanssa hiekkalaatikkoympäristöissä ..vaikka nyt virtuaali-infran kulmassa. Laiterikkoihin voi varautua nasevasti hankkimalla kaikki IT-härvelit SAMALTA vendorilta, johon voit kikkailla myös ylläpitosopimuksia kylkeen, sekä lokittamalla käyttöikää valmistajan ilmoittamaa MtbF -arvoa vastaan ja kylmästi vain uusimalla huoltoikkunan(yöllä) aikana ne laitteet, jotka lähestyvät 90% tästä aika-arvosta. Ketjun tulisi olla myös hallittavissa siitä hetkestä kun se tulee ISP:n verkosta infraan aina yksittäiseen työasemaan asti.
Onhan se kiva, että osastoÖ saa ristikytkettyä nopsaan ne neljä työasemapaikaa yllätysrekryjen vuoksi ja extrakytkentöjen mahdollistajana toimii epävarma piece of consumer plastic pienkytkin joka haaroittaa yhtä porttia kerroskytkimestä. Purkkavirityksillä on pahana tapana jäädä haamuilemaan tuotantoon pitkiksi aikoihin ja ne kusevat yllätyskovaa adminin nilkoilla juuri silloin kun niin ei saisi käydä.
Ciscon laitteissa portit on sitten btw. alhaalla oletuksena niihin kohdistuneiden muutosten jälkeen. Juniperin palomuuriaparaattien firmiksen on koodannut joku käsittämätön nero planneetta X:ltä.
Planeetta syttyy tuleen jos teletilan ristikytkentäpaneelin merkinnät ei natsaa seinän verkkopistokkeiden tarrojen kanssa. Näihin issueihin kannattaa yleensä puuttua hetiheti ja komentaa kesäduunari vetämään yöllä ristikytkökset uusiksi.

Toinen kova EP-levelin kriisien aiheuttaja on “hallittujen” muutosten yllättävä käyttäytyminen pitkin infraa, varsinkin jos kyseessä on pitkään ylöspäin skaalautunut ympäristö. Se yksi unohdettu rivi domain controllerin LMHOSTS -tietueessa voi olla yllättävän sähäkkä kun controllerit aloittavat replikointiliikenteen. Kaikki kovakoodatut arvot kusevat joskus ja varsinkin Microsoftin tuotteilla ne aiheuttavat toudella outoja tilanteita välillä.
Palataan siihen dokumentinhallintaan, jos on tuotantokäytössä järjestelmä niin tästä on löydyttävä kuvaus, ylläpito ja realaatiokuvaukset.
Jos juurisyynä(tai vahvasti epäilet) on Microsoftin julkaisema tietoturvapäivitys niin kannattaa ennen hätäpäistä downgradea vähän googletella fiiliksiä muualta; et ole kuitenkaan se maailman ainut MS-admini, jos epäilet että patchi on särkenyt sinulta jotain niin aivan takuulla niin on tapahtunut myös muualla. Hän joka adminoi WSUSta tms. palvelua on hyvä ja lukee notesit läpi ja testaa sandboxillaan päivitykset ennen releaseä tuotantoon.

IIS palveluna korjautuu lähes aina palvelun bootilla, ylipäätään buutti kaiken muutti on kovaa valuuttaa only MS ympäristössä. Eli ennenku lyöt bladesta virrat poikki niin buuttaapa palvelut ensin. Tiedät kuitenkin, että joku integraatio kusee pahasti jos huomaat koodaavasi skriptiä, jolla buutataan palveluX joka yö.

Kun shoppailet uusia nappuloita(tietojärjestelmiä) muiden iloksi niin tee selväksi, että softa taipuu sinun infraasi; infraa ei taivuteta yksittäisen softan tarpeisiin esim. workstation policyillä. Vaadi laatua ja sanktioi toimitukset tarkkaan. Homma on valmis kun pilottiryhmä näyttää peukkua. Tarve uuden namiskan hankintaan tuli sitten toivottavasti sidosryhmiltäsi eikös joo?

Viikset juoksee suuhun ja suuta kuivaa. Pakko lopetella.
Ja tiedän, tämä kaikki voi vaikutta ihan basic naivistiselta utopialta, mutta sinä lukemaasi tyytymätön voit aina kirjailla omaan blokiisi miten esmes pelastit kaiken open source hullutuksillasi.

Optimaalisin skripti syntyy muuten tasan 1,79 promillen humalassa, jos BaC dingaa 1,8aan niin vaihe kääntyy ja tuloksena on aivan kauheaa dadaa. Muista kommentoida.

Ylityöt on aina indikaatio poorly designed and/or implemented resurssien allokoinnista.

-K

Comments are closed.

1 Comment

  • splahd

    http://xkcd.com/323/ Ameerikassa ei osata kunnolla koodata … eiku juoda.

    05/20/14 – 3:54 pm

Balloons theme by
Moargh.de