Banki.ru-portaalin toimintajohtaja Andrey Nikolsky puhui viime vuoden konferenssissa orpopalveluista: kuinka tunnistaa orpo infrastruktuurista, miksi orpopalvelut ovat huonoja, mitä niille tehdä ja mitä tehdä, jos mikään ei auta.
Leikkauksen alla on tekstiversio raportista.
Hei kollegat! Nimeni on Andrey, johdan toimintoja osoitteessa Banki.ru.
Meillä on suuria palveluita, nämä ovat sellaisia monoliittisia palveluita, on palveluita klassisemmassa mielessä ja on hyvin pieniä. Työläis-talonpoika-terminologiassani sanon, että jos palvelu on yksinkertainen ja pieni, se on mikro, ja jos se ei ole kovin yksinkertainen ja pieni, niin se on vain palvelu.
Palveluiden plussat
Käyn nopeasti läpi palveluiden edut.
Ensimmäinen on skaalaus. Voit nopeasti tehdä jotain palvelussa ja aloittaa tuotannon. Olet vastaanottanut liikennettä, olet kloonannut palvelun. Sinulla on enemmän liikennettä, olet kloonannut sen ja elä sen kanssa. Tämä on hyvä bonus, ja periaatteessa, kun aloitimme, pidettiin meille tärkeimpänä, miksi teemme kaiken tämän.
Toiseksi, eristetty kehitys, kun sinulla on useita kehitystiimejä, jokaisessa tiimissä useita eri kehittäjiä ja jokainen tiimi kehittää omaa palveluaan.
Joukkueissa on vivahde. Kehittäjät ovat erilaisia. Ja siellä on esim. . Näin tämän ensimmäisen kerran Maxim Dorofejevin kanssa. Joskus lumihiutale-ihmisiä on joissakin ryhmissä ja ei toisissa. Tämä tekee yrityksen eri palveluista hieman epätasaista.
Katso kuvaa: tämä on hyvä kehittäjä, hänellä on suuret kädet, hän voi tehdä paljon. Suurin ongelma on, mistä nämä kädet tulevat.
Palvelut mahdollistavat erilaisten ohjelmointikielien käytön, jotka sopivat paremmin erilaisiin tehtäviin. Osa palveluista on Go:ssa, osa Erlangissa, osa Rubyssa, osa PHP:ssä, osa Pythonissa. Yleisesti ottaen voit laajentaa hyvin laajasti. Tässäkin on vivahteita.
Palvelukeskeinen arkkitehtuuri koskee ensisijaisesti devoppeja. Eli jos sinulla ei ole automaatiota, käyttöönottoprosessia ei ole, jos määrität sen manuaalisesti, kokoonpanosi voivat muuttua palveluinstanssista toiseen ja sinun on mentävä sinne tekemään jotain, niin olet helvetissä.
Sinulla on esimerkiksi 20 palvelua ja sinun on otettava käyttöön käsin, sinulla on 20 konsolia ja painat samanaikaisesti "enter" kuin ninja. Se ei ole kovin hyvä.
Jos sinulla on palvelu testauksen jälkeen (jos testausta toki on), ja sinun täytyy silti viimeistellä se tiedostolla, jotta se toimisi tuotannossa, minulla on myös sinulle huonoja uutisia.
Jos luotat tiettyihin Amazon-palveluihin ja työskentelet Venäjällä, kaksi kuukautta sitten sinulla oli myös "Kaikki ympärillä on tulessa, olen kunnossa, kaikki on siistiä."
Käytämme Ansiblea käyttöönoton automatisoimiseen, Puppetia konvergenssiin, Bamboota käyttöönoton automatisoimiseen ja Confluencea kuvaamaan sitä kaikkea.
En käsittele tätä yksityiskohtaisesti, koska raportti käsittelee enemmän vuorovaikutuskäytäntöjä, ei teknistä toteutusta.
Meillä on esimerkiksi ollut ongelmia, kun palvelimella oleva Puppet toimii Ruby 2:n kanssa, mutta jotkut sovellukset on kirjoitettu Ruby 1.8:lle, eivätkä ne toimi yhdessä. Jotain menee pieleen siellä. Ja kun sinun on käytettävä useita Rubyn versioita yhdellä koneella, sinulla alkaa yleensä olla ongelmia.
Esimerkiksi, annamme jokaiselle kehittäjälle alustan, jolla on suunnilleen kaikki mitä meillä on, kaikki palvelut, joita voidaan kehittää, jotta hänellä on eristetty ympäristö, hän voi rikkoa sen ja rakentaa sen haluamallaan tavalla.
Sattuu niin, että tarvitset jotain erityisesti koottua pakettia, joka tukee jotain siellä. Se on aika rankkaa. Kuuntelin raportin, jossa Docker-kuva painaa 45 Gt. Linuxissa se on tietysti yksinkertaisempaa, siellä kaikki on pienempää, mutta silti tilaa ei ole tarpeeksi.
No, on olemassa ristiriitaisia riippuvuuksia, kun yksi projektin osa riippuu yhden version kirjastosta, toinen osa projektista riippuu toisesta versiosta, eikä kirjastoja asenneta ollenkaan yhteen.
Meillä on sivustoja ja palveluita PHP 5.6:ssa, häpeämme niitä, mutta mitä voimme tehdä? Tämä on yksi sivustomme. PHP 7:ssä on sivustoja ja palveluita, niitä on enemmän, emme häpeä niitä. Ja jokaisella kehittäjällä on oma tukikohta, jossa hän iloisesti sahaa.
Jos kirjoitat yrityksessä yhdellä kielellä, kolme virtuaalikonetta kehittäjää kohden kuulostaa normaalilta. Jos sinulla on eri ohjelmointikieliä, tilanne pahenee.
Sinulla on sivustoja ja palveluita tästä, tästä, sitten toinen sivusto Golle, yksi sivusto Rubylle ja joitain muita Rediä sivulla. Tämän seurauksena kaikki tämä muuttuu suureksi tukikenttään, ja koko ajan osa siitä voi rikkoutua.
Siksi korvasimme ohjelmointikielen edut erilaisten puitteiden käytöllä, koska PHP-kehykset ovat melko erilaisia, niillä on erilaiset ominaisuudet, erilaiset yhteisöt ja erilainen tuki. Ja voit kirjoittaa palvelun niin, että sinulla on jo jotain valmiina sitä varten.
Jokaisella palvelulla on oma tiiminsä
Suurin useiden vuosien aikana kiteytynyt etumme on, että jokaisella palvelulla on oma tiiminsä. Tämä on kätevää suurelle projektille, voit säästää aikaa dokumentaatiossa, johtajat tuntevat projektinsa hyvin.
Voit lähettää tehtäviä helposti tuesta. Esimerkiksi vakuutuspalvelu katkesi. Ja heti vakuutusasioista vastaava tiimi lähtee korjaamaan sitä.
Uusia ominaisuuksia syntyy nopeasti, sillä kun sinulla on yksi atomipalvelu, voit nopeasti ruuvata siihen jotain.
Ja kun katkaiset palvelusi, ja tämä väistämättä tapahtuu, et vaikuttanut muiden ihmisten palveluihin, eivätkä muiden tiimien kehittäjät juokse luoksesi ja sano: "Ay-ay, älä tee sitä."
Kuten aina, on vivahteita. Meillä on vakaat joukkueet, johtajat ovat naulattu joukkueeseen. Asiakirjat ovat selkeät, johtajat seuraavat tarkasti kaikkea. Jokaisella tiimillä, jossa on esimies, on useita palveluita, ja niillä on tietty osaamispiste.
Jos joukkueet kelluvat (käytetään myös joskus tätä), on olemassa hyvä menetelmä nimeltä "tähtikartta".
Sinulla on luettelo palveluista ja ihmisistä. Asteriski tarkoittaa, että henkilö on tämän palvelun asiantuntija, kirja tarkoittaa, että henkilö opiskelee tätä palvelua. Henkilön tehtävänä on vaihtaa kirjanen tähdeksi. Ja jos palvelun eteen ei kirjoiteta mitään, ongelmat alkavat, joista puhun edelleen.
Miten orpopalvelut näkyvät?
Ensimmäinen ongelma, ensimmäinen tapa saada orpopalvelu infrastruktuuriisi on ihmisten erottaminen. Onko kukaan koskaan noudattanut määräaikoja ennen tehtävien arviointia? Joskus käy niin, että määräajat ovat tiukkoja ja dokumentoinnille ei yksinkertaisesti ole tarpeeksi aikaa. "Meidän on luovutettava palvelu tuotantoon, sitten lisäämme sen."
Jos tiimi on pieni, sattuu olemaan yksi kehittäjä, joka kirjoittaa kaiken, loput ovat siivillä. "Kirjoitin perusarkkitehtuurin, lisätään käyttöliittymät." Sitten jossain vaiheessa esim. esimies lähtee. Ja tänä aikana, kun johtaja on lähtenyt eikä uutta ole vielä nimitetty, kehittäjät päättävät itse, minne palvelu menee ja mitä siellä tapahtuu. Ja kuten tiedämme (palataan pari dioja taaksepäin), joissakin joukkueissa on lumihiutaleihmisiä, joskus lumihiutaleryhmän johtaja. Sitten hän lopettaa, ja saamme orpopalvelun.
Samalla tuen ja liiketoiminnan tehtävät eivät katoa, vaan päätyvät ruuhkaan. Jos palvelun kehittämisessä on arkkitehtonisia virheitä, ne päätyvät myös ruuhkaan. Palvelu heikkenee pikkuhiljaa.
Kuinka tunnistaa orpo?
Tämä lista kuvaa tilannetta hyvin. Kuka oppi mitään infrastruktuuristaan?
Dokumentoiduista kiertotavoista: palvelu on olemassa ja yleisesti ottaen se toimii, siinä on kaksisivuinen käsikirja kuinka sen kanssa työskennellä, mutta kukaan ei tiedä kuinka se toimii sisällä.
Tai esimerkiksi on olemassa jonkinlainen linkin lyhentäjä. Esimerkiksi meillä on tällä hetkellä käytössä kolme linkinlyhennystä eri tarkoituksiin eri palveluissa. Nämä ovat vain seurauksia.
Nyt olen ilmeisen kapteeni. Mitä pitäisi tehdä? Ensin meidän on siirrettävä palvelu toiselle johtajalle, toiselle tiimille. Jos tiiminvetäjäsi ei ole vielä irtisanoutunut, niin tähän toiseen tiimiin, kun ymmärrät, että palvelu on kuin orpo, sinun tulee ottaa mukaan joku, joka ymmärtää siitä ainakin jotain.
Tärkeintä: sinulla on oltava siirtomenettelyt verellä. Meidän tapauksessamme yleensä valvon tätä, koska tarvitsen kaiken toimiakseen. Esimiehet tarvitsevat sen toimitettavaksi nopeasti, eikä heille ole enää niin tärkeää, mitä sille tapahtuu myöhemmin.
Seuraava tapa tehdä orpo on "Teemme sen ulkoistettuna, se on nopeampi ja sitten luovutamme sen tiimille." On selvää, että jokaisella on joukkueessa suunnitelmia, vuoro. Usein yritysasiakas ajattelee, että ulkoistaja tekee saman kuin yrityksen tekninen osasto. Vaikka heidän motivaattorinsa ovat erilaiset. Ulkoistamisessa on outoja teknologisia ratkaisuja ja outoja algoritmisia ratkaisuja.
Meillä oli esimerkiksi palvelu, jossa Sfinksiä oli useissa odottamattomissa paikoissa. Kerron myöhemmin, mitä minun piti tehdä.
Ulkoistajilla on itse kirjoitetut puitteet. Tämä on vain paljas PHP ja copy-paste edellisestä projektista, josta löytyy kaikenlaista. Käyttöönottokomentosarjat ovat suuri haitta, kun joudut käyttämään monimutkaisia Bash-komentotiedostoja useiden rivien vaihtamiseen jossakin tiedostossa, ja näitä käyttöönottoskriptejä kutsuu jokin kolmas komentosarja. Tämän seurauksena muutat käyttöönottojärjestelmää, valitset jotain muuta, hyppäät, mutta palvelusi ei toimi. Koska siellä oli tarpeen laittaa 8 linkkiä lisää eri kansioiden välille. Tai tapahtuu niin, että tuhat levyä toimii, mutta satatuhatta ei enää toimi.
Jatkan kapteenina. Ulkoistetun palvelun hyväksyminen on pakollinen toimenpide. Onko kenellekään koskaan tullut ulkoistettua palvelua, jota ei ole hyväksytty missään? Tämä ei tietenkään ole yhtä suosittua kuin orpopalvelu, mutta silti.
Palvelu on tarkistettava, palvelu on tarkistettava, salasanat on vaihdettava. Meillä oli tapaus, kun he antoivat meille palvelun, siellä on hallintapaneeli "if login == 'admin' && password == 'admin'...", se on kirjoitettu suoraan koodiin. Istumme ja ajattelemme, ja ihmiset kirjoittavat tämän vuonna 2018?
Myös tallennuskapasiteetin testaus on välttämätön asia. Sinun täytyy katsoa, mitä tapahtuu sadalle tuhannelle levylle, jo ennen kuin otat tämän palvelun tuotantoon jonnekin.
Ei pitäisi olla häpeä lähettää palvelua parannettavaksi. Kun sanot: "Emme ota tätä palvelua vastaan, meillä on 20 tehtävää, tee ne, niin me hyväksymme", tämä on normaalia. Omatuntoasi ei pitäisi loukata siitä, että olet perustamassa johtajaa tai että yritys tuhlaa rahaa. Silloin yritys kuluttaa enemmän.
Meillä oli tapaus, kun päätimme ulkoistaa pilottiprojektin.
Se toimitettiin ajallaan, ja tämä oli ainoa laatukriteeri. Siksi teimme toisen pilottiprojektin, joka ei ollut enää edes pilotti. Nämä palvelut hyväksyttiin, ja hallinnollisin keinoin he sanoivat: tässä on koodisi, tässä on tiimi, tässä on esimiehesi. Palvelut ovat itse asiassa jo alkaneet tuottaa voittoa. Samalla he ovat itse asiassa edelleen orpoja, kukaan ei ymmärrä heidän toimintaansa, ja esimiehet tekevät parhaansa kieltääkseen tehtävänsä.
On toinenkin hieno käsite - sissien kehittäminen. Kun jokin osasto, yleensä markkinointiosasto, haluaa testata hypoteesia ja tilaa koko palvelun ulkoistetuksi. Liikenne alkaa tunkeutua siihen, suljetaan asiakirjat, allekirjoitetaan asiakirjat urakoitsijan kanssa, ryhdytään toimiin ja sanotaan: "Kaverit, meillä on palvelu täällä, sillä on jo liikennettä, se tuo meille rahaa, hyväksytään se." Olimme kuin "Oppa, kuinka se voi olla."
Ja toinen tapa saada orpopalvelu: kun joku tiimi yhtäkkiä latautuu, johto sanoo: "Siirretään tämän tiimin palvelu toiselle tiimille, sillä on pienempi kuorma." Ja sitten siirrämme sen kolmanteen tiimiin ja vaihdamme manageria. Ja lopulta meillä on taas orpo.
Mikä orpoja vaivaa?
Kuka ei tiedä, tämä on Ruotsissa nostettu taistelulaiva Wasa, joka on kuuluisa siitä, että se upposi 5 minuuttia laukaisun jälkeen. Ja Ruotsin kuningas ei muuten teloittanut ketään tästä syystä. Sen rakensivat kaksi sukupolvea insinöörejä, jotka eivät tienneet kuinka rakentaa tällaisia aluksia. Luonnollinen vaikutus.
Laiva olisi muuten voinut uppoa paljon pahemmalla tavalla, esimerkiksi kun kuningas jo ratsasti sillä jossain myrskyssä. Ja niin hän hukkui heti, Agilen mukaan on hyvä epäonnistua aikaisin.
Jos epäonnistumme ajoissa, ei yleensä ole ongelmia. Esimerkiksi hyväksynnän aikana se lähetettiin tarkistettavaksi. Mutta jos epäonnistumme jo tuotannossa, kun rahaa sijoitetaan, voi tulla ongelmia. Seuraukset, kuten niitä liiketoiminnassa kutsutaan.
Miksi orpopalvelut ovat vaarallisia:
- Palvelu saattaa katketa yllättäen.
- Huollon korjaaminen kestää kauan tai sitä ei korjata ollenkaan.
- Turvallisuusongelmat.
- Ongelmia parannuksissa ja päivityksissä.
- Jos tärkeä palvelu hajoaa, yrityksen maine kärsii.
Mitä tehdä orpopalveluille?
Toistan mitä tehdä. Ensinnäkin asiakirjat pitää olla. 7 vuotta Banki.ru:lla opetti minulle, että testaajien ei pitäisi ottaa kehittäjien sanaa, eikä operaatioiden pitäisi ottaa kaikkien sanaa. Meidän on tarkistettava.
Toiseksi on tarpeen kirjoittaa vuorovaikutuskaavioita, koska tapahtuu niin, että huonosti vastaanotetut palvelut sisältävät riippuvuuksia, joista kukaan ei ole sanonut. Esimerkiksi kehittäjät asensivat palvelun avaimeensa johonkin Yandex.Mapsiin tai Dadataan. Sinulta on loppunut vapaa raja, kaikki on rikki, etkä tiedä mitä tapahtui. Kaikki tällaiset rakeet on kuvattava: palvelu käyttää Dadataa, tekstiviestejä, jotain muuta.
Kolmanneksi työskentely teknisen velan kanssa. Kun teet jonkinlaisia kainalosauvoja tai otat vastaan palvelun ja sanot, että jotain on tehtävä, sinun on varmistettava, että se tehdään. Koska silloin voi käydä ilmi, ettei pieni reikä ole niin pieni, ja putoat sen läpi.
Arkkitehtuuritehtävissä meillä oli tarina Sfinksistä. Yksi palveluista käytti Sphinxiä listojen syöttämiseen. Vain sivutettu luettelo, mutta se indeksoitiin uudelleen joka ilta. Se koottiin kahdesta indeksistä: yksi iso indeksoitiin joka ilta, ja siihen ruuvattiin myös pieni indeksi. Joka päivä, 50 %:n todennäköisyydellä joko pommittaa tai ei, indeksi kaatui laskennan aikana, ja uutisemme eivät päivittyneet pääsivulle. Aluksi indeksin uudelleenindeksointi kesti 5 minuuttia, sitten indeksi kasvoi, ja jossain vaiheessa uudelleen indeksointi alkoi kestää 40 minuuttia. Kun leikkasimme tämän pois, huokaisimme helpotuksesta, koska oli selvää, että kuluisi vielä vähän aikaa ja indeksimme indeksoidaan uudelleen koko ajan. Tämä on epäonnistuminen portaalillemme, uutisia ei ole kahdeksaan tuntiin - siinä kaikki, liiketoiminta on pysähtynyt.
Suunnittele työskentely orpopalvelun kanssa
Itse asiassa tämä on erittäin vaikea tehdä, koska devops on viestintää. Haluat olla hyvissä väleissä kollegojesi kanssa, ja kun lyöt kollegoitasi ja esimiehiäsi säännöillä päähän, heillä voi olla ristiriitaisia tunteita niitä ihmisiä kohtaan, jotka tekevät niin.
Kaikkien näiden seikkojen lisäksi on toinen tärkeä asia: tiettyjen henkilöiden on oltava vastuussa jokaisesta tietystä palvelusta, jokaisesta käyttöönottoprosessin tietystä osasta. Kun ei ole ihmisiä ja sinun täytyy houkutella muita ihmisiä, tutkia tätä koko asiaa, siitä tulee vaikeaa.
Jos kaikki tämä ei auttanut ja orpopalvelusi on edelleen orpo, kukaan ei halua ottaa sitä vastaan, asiakirjoja ei ole kirjoitettu, tähän palveluun kutsuttu tiimi kieltäytyy tekemästä mitään, on yksinkertainen tapa - tehdä uudelleen kaikki .
Eli otat palvelun vaatimukset uudestaan ja kirjoitat uuden palvelun, paremmin, paremmalla alustalla, ilman outoja teknisiä ratkaisuja. Ja siirryt siihen taistelussa.
Meillä oli tilanne, kun otimme palvelun Yii 1:lle ja tajusimme, että emme voineet kehittää sitä edelleen, koska meiltä loppui kehittäjät, jotka osasivat kirjoittaa hyvin Yii 1:llä. Kaikki kehittäjät kirjoittavat hyvin Symfony XNUMX:lla. Mitä tehdä? Varasimme aikaa, jakoimme tiimin, jakoimme johtajan, kirjoitimme projektin uudelleen ja siirsimme sujuvasti liikenteen siihen.
Tämän jälkeen vanha palvelu voidaan poistaa. Tämä on suosikkini, kun täytyy ottaa ja puhdistaa jokin palvelu konfiguraatiohallintajärjestelmästä ja sitten käydä läpi ja katsoa, että kaikki tuotannossa olevat autot on poistettu käytöstä, jotta kehittäjille ei jää jälkiä. Arkisto pysyy Gitissä.
Tästä halusin puhua, olen valmis keskustelemaan, aihe on holivar, monet ovat uineet siinä.
Diat sanoivat, että yhdistät kielet. Esimerkkinä oli kuvien koon muuttaminen. Onko todella tarpeen rajoittaa se tiukasti yhteen kieleen? Koska kuvien koon muuttaminen PHP:llä voidaan itse asiassa tehdä Golangissa.
Itse asiassa se on valinnainen, kuten kaikki käytännöt. Ehkä joissain tapauksissa se on jopa ei-toivottavaa. Mutta sinun on ymmärrettävä, että jos sinulla on tekninen osasto 50 hengen yrityksessä, joista 45 on PHP-asiantuntijoita, toiset 3 ovat devoppeja, jotka tuntevat Pythonin, Ansiblen, Puppetin ja jotain sellaista, ja vain yksi heistä kirjoittaa joissakin. jonkinlainen Go-kuvan koonmuutospalvelu, jonka jälkeen asiantuntemus kulkee mukana. Ja samalla sinun on etsittävä markkinakohtainen kehittäjä, joka osaa tämän kielen, varsinkin jos se on harvinaista. Eli organisaation näkökulmasta tämä on ongelmallista. Devopsin näkökulmasta sinun ei tarvitse vain kloonata valmiita pelikirjoja, joita käytät palveluiden käyttöönotossa, vaan sinun on kirjoitettava ne uudelleen.
Rakennamme parhaillaan palvelua Node.js:lle, ja tämä on vain lähistöllä oleva alusta jokaiselle kehittäjälle erillisellä kielellä. Mutta istuimme ja ajattelimme, että peli oli kynttilän arvoinen. Eli tämä on kysymys, jonka voit istua ja miettiä.
Miten seuraat palveluitasi? Kuinka keräät ja valvot lokeja?
Keräämme lokit Elasticsearchissa ja laitamme ne Kibanaan ja siellä käytetään erilaisia keräilijöitä riippuen siitä onko kyseessä tuotanto- vai testiympäristö. Jossain Metsämies, jossain muualla jotain muuta, en muista. Ja tietyissä palveluissa on edelleen joitain paikkoja, joissa asennamme Telegrafin ja kuvaamme muualla erikseen.
Kuinka elää Puppetin ja Ansiblen kanssa samassa ympäristössä?
Itse asiassa meillä on nyt kaksi ympäristöä, toinen on Puppet ja toinen Ansible. Pyrimme yhdistämään ne. Ansible on hyvä kehys alkuasennusta varten, Puppet on huono kehys alkuasennukseen, koska se vaatii käytännön työtä suoraan alustalla, ja Puppet varmistaa konfiguraatioiden lähentymisen. Tämä tarkoittaa, että alusta pitää itsensä ajan tasalla, ja jotta ansibilisoitu kone pysyy ajan tasalla, sinun täytyy ajaa sillä pelikirjoja koko ajan tietyllä taajuudella. Siinä se ero.
Miten ylläpidät yhteensopivuutta? Onko sinulla asetuksia sekä Ansiblessa että Puppetissa?
Tämä on meidän suuri tuskamme, pidämme yhteensopivuutta käsillämme ja mietimme, miten tästä kaikesta päästään nyt jonnekin eteenpäin. Osoittautuu, että Puppet julkaisee paketteja ja ylläpitää siellä joitain linkkejä, ja esimerkiksi Ansible rullaa koodin ja säätää uusimmat sovellusasetukset siellä.
Esitys käsitteli Rubyn eri versioita. Mikä ratkaisu?
Kohtasimme tämän yhdessä paikassa, ja meidän on pidettävä se päässämme koko ajan. Sammutimme yksinkertaisesti Rubyn osan, joka ei ollut yhteensopiva sovellusten kanssa, ja pidimme sen erillään.
Tämän vuoden konferenssi järjestetään 7. joulukuuta Technopoliksessa. Otamme vastaan raportteja 11. asti. meille, jos haluat puhua.
Ilmoittautuminen osallistujille on auki, tule mukaan!
Lähde: will.com