Kuinka käytin joukkoratkaisuja auttamaan Keralaa tulvien pelastustoimenpiteissä.

Yön yli tein verkkosivun, jonka avulla ihmiset voivat löytää kiireellisiä pyyntöjä

Elokuussa 2018 tulvat tuhoavat Keralan valtion. Kuudesosa sen väestöstä kärsi suoraan. Valtio on aiheuttanut 3B dollarin omaisuusvahinkoa.

Olen Arnav, 18-vuotias Bangaloresta, joka päätti koulun maaliskuussa. Tulvien sattuessa törmäsin Keralan pelastusprojektiin. Tämä oli vapaaehtoisten kehittäjien liike, joka ratkaisee verkkoa käyttävien Keralan tulvien teknisiin haasteisiin.

Verkkosivusto tarjosi tärkeitä palveluita. Se keräsi uhrien apupyyntöjä. Se auttoi vapaaehtoisia ja pelastajia paikantamaan heidät ja löytämään hätäleirejä. Se tarjosi visualisointeja katastrofivalmiusjoukkoille.

Tutkiessani projektia GitHubissa ja Slackissa löysin erityisen ongelman, jonka tunsin pystyväni ratkaisemaan.

Liian monta pyyntöä

Massiivisen kerran 100-vuotisen tulvan jälkeen pyydettiin paljon avunpyyntöjä.

Katsoin uusien pyyntöjen saapuvan joka kerta, kun päivitin API-päätepisteen pelastussivustolla. Kun löysin sen ensimmäisen kerran, vietin melkein puoli tuntia vain lukemalla ihmisten pyyntöjä.

He olivat ahdistavia. Vanhoja, sairaita ja loukkaantuneita, raskaana olevia naisia ​​ja imeväisiä koskevia pyyntöjä. Jotkut ilmoittavat rakennukset romahduksen tai tulvavesien nousun partaalla. Jotkut olivat muualla asuvista ihmisistä, jotka eivät pystyneet tavoittamaan sukulaisia ​​Keralassa.

Mutta ahdistavat olivat keskellä pyyntöjä, jotka eivät vaikuttaneet olevan välittömiä tai joilla ei ollut vähän tietoja.

Ja nämä olivat vain englanninkielisiä. En voinut lukea Malayalamissa (keralan kieli) kirjoitettuja pyyntöjä.

Se sai minut pohtimaan: kuinka pyynnöt priorisoitiin? Kysyin ympäri. Tosiaan, ihmiset huomauttivat, että tämä oli todellinen asia.

Tietojen ymmärtäminen

Ajattelin kahta lähestymistapaa pyyntöjen kiireellisyyden selvittämiseksi.

Luonnollinen kielenkäsittely (NLP)

Sanat kuten 'kiireellinen', 'pikkulasten vauva', 'raskaana' tai 'loukkuun jäänyt' ilmaisivat kiireellisyyttä, ja niitä voidaan käyttää pyyntöjen luokittelemiseen.

Mutta tiedoissa oli useita ongelmia: pyynnöt olivat englanniksi ja malayalamia. Ja joskus Malayalam kirjoitettiin englanniksi.

Monet kirjoitettiin kiireellisesti.

Jotkut ehdottivat käännöksiä ensin englanniksi ennen NLP: n soveltamista. Mutta kääntäminen on tappiollista, ja olin varma, että tämä ei toimisi.

Ja lopuksi tunsin, että kiireellisyys oli suurelta osin kontekstuaalinen. Voisiko NLP käsitellä sitä hyvin? Nykyinen tuntemusanalyysi voi kertoa, onko teksti positiivinen, negatiivinen, onnellinen vai surullinen. Mutta se ei mittaa kiireellisyyttä.

Ja uuden mallin kehittämiselle ei ollut aikaa. Erityisesti ottaen huomioon kieliongelma.

Joukkoistaminen

Olin varma, että ihmiset tekevät jonkin aikaa vapaaehtoista tunnistaakseen kiireelliset pyynnöt.

Heillä on järkevä tieto, joka viittaa kiireellisyyteen, jossa tietokoneet eivät ole hyviä.

Kuvittelin verkkosivuston, joka haki ja näyttää pyynnöt pelastussivustolta. Vapaaehtoiset arvioivat kiireellisyyttä asteikolla, joka ei muuttunut kiireellisestä kriittiseksi (arvot 0–3), ja mahdollisuus roskapostiksi (–1). He voivat ohittaa pyynnöt, jos he eivät osaa kieltä.

Joten sain töihin.

Toteutus

Ajattelin ensin joukkotuho-ominaisuuden rakentamista keralarescue.in-sivustoon

Projekti oli avoimen lähdekoodin. Monet rakensivat erillisiä, mutta linkitettyjä työkaluja samaan alustaan. Minulle oli järkevää rakentaa asia siihen.

Mutta minulla oli joitain huolenaiheita:

  1. En ollut varma, toimiiko idea. En halunnut jättää kuormitusta alustalle, josta monet olivat riippuvaisia.
  2. Alusta kirjoitettiin Djangossa PostgreSQL: llä. Minulla ei ole vähän tuntemusta niihin, enkä halunnut kokeilla-oppia.
  3. Tarkastelujärjestelmä voisi estää iteroinnin nopeasti.

Joten päätin luoda työkaluni riippumatta pääalustasta.

Jos se toimisi, saisin heidät yhdistämään tietoni. Jos se epäonnistui? Eh.

Keskiyön öljy

Kellonaika oli jo kello 1.00. Asetin tavoitteeksi saada sivustoni viiden tunnin sisällä, joten se olisi valmis, kun ihmiset heräävät.

Ideana oli käyttää keralarescue.in-sovellusliittymän päätepistettä apupyyntöjen näyttämiseen. Tietysti välimuistiin sen loppupäässäni, jotta ei rasitettaisi pääsivustoa.

Aloin kehittää alustaa. Aloitin luomalla datamalleja. Sitten työskentelin toimintojen ja API-päätepisteiden kanssa. Lopulta aloitin työn eteenpäin. Pinooni sisälsi Firebase ja VueJS nopeisiin prototyyppisyistä.

Aion käyttää Wilsonin luottamusvälejä pisteiden arviointiin. (Käytetään luottamuslajitteluun Redditissä) Ne ovat parannus yksinkertaisiin keskiarvoihin verrattuna, koska niiden osuus luokituksista on lukumäärä.

Mutta olin kiire, joten päätin toteuttaa tämän myöhemmin. Ilman tietoja tästä ei ollut paljon hyötyä.

'Yksinkertaisuus' on klisee. Mutta huomasin, että se toimii. Asiat näyttivät paranevan, kun leikkasin monimutkaisuutta. Kirjoitin yksinkertaisia ​​datamalleja. Poistin reCAPTCHA: n ja todennuksen olettaen, että en houkuttele haitallisia käyttäjiä.

Noin kello 8.00 mennessä prototyyppini oli valmis. Ja olin valmis nukkumaan. Lähetin linkin GitHubiin ja menin sänkyyn juuri ensimmäisen sivun katselun alkaessa Google Analyticsissa.

Minulla ei ollut vaikeuksia nukahtaa.

Ihmisten ottaminen alukseen

Minulla oli käyttäjiä.

Kun heräsin keskipäivällä, tarkistin analytiikan ennen mitään muuta. ~ 30 käyntiä. Ja minulla oli tällä hetkellä kaksi käyttäjää verkossa. Keralan osavaltiosta. Woah.

Palaute oli positiivista. Ja olin kerännyt melko vähän tietoa. Jatkoin alustani parantamista päivän aikana.

  • Poistin roskapostin vaihtoehdon. Sain tietää, että ihmiset eivät olleet varmoja, mitkä pyynnöt olivat roskapostia. Monista puuttui tietoa. Ne voivat olla täysin päteviä pyyntöjä kiireellisiltä ihmisiltä tai ihmisiltä, ​​joiden tekniikka ei ollut hyvä.
  • Toteutin Wilson-pisteet. Loin API-päätepisteen, joka palautti luottamusarvon välillä 0 ja 1 kaikkien tähän mennessä kerättyjen käyttäjäarvioiden perusteella. Ajatuksena oli saada keralarescue.in käyttämään tätä päätepistettä päivittääkseen tietojoukkoa säännöllisesti. Arvon avulla voitaisiin lajitella ja löytää kiireellisimmät pyynnöt
  • Lisäsin sivun kiireellisten pyyntöjen esittämistä varten. Halusin tehdä tästä työkalusta hyötyä mahdollisimman pian.

Noin klo 16 päätin ilmoittaa siitä Slack and Github -sivustolla.

Tämä osoittautui käännepisteeksi, ja seuraavien tuntien ajan sivustolla oli 20–30 käyttäjää verkossa. He olivat kaikkialta Intiasta ja myös Yhdysvalloista. Keralan käyttäjät jatkoivat työskentelyä myöhään iltaan, lajittelupyyntöjä kello 2:00.

Huomasin, että ihmiset suhtautuivat hitaammin luokituspyyntöihin kuin odotin.

Seuraavana iltana oppisin miksi.

Triaarausryhmä

Seuraavaan päivään mennessä olin valmis suurin osa dev-töistä. Monet ihmiset alkoivat ottaa minuun yhteyttä. He pitivät projektistani - etenkin yksinkertaisesta käyttöliittymästä.

Illalla sain DM: n Twitterissä joltakin nimeltä Nishanth, joka kysyi, voisiko verkkosivustoni käyttää triaatiopyyntöihin. Saimme puhelun, ja kuvasin kuinka väkijoukot voivat auttaa määrittämään pyyntöjen kiireellisyyden.

Hän lisäsi minut sadan jäseniseen ryhmään WhatsAppissa. Näyttää siltä, ​​että nämä hienot ihmiset ovat käyttäneet verkkosivustoni täysin eri tavalla.

He soittivat aktiivisesti hakijoita ja saivat päivityksiä tilanteestaan. He arvioivat kiireellisyyttä eivätkä perustu tekstin sisältöön vaan keskustelivat tosiasiallisesti kärsivien ihmisten kanssa. WOAH.

Tajusin, että tietokantani sisälsi arvokkaampaa tietoa kuin luulin. Autimme suoraan vapaaehtoisia tavoittamaan uhrit. Työni kiitolliset viestit rullasi puhelimeen.

Tietolähteen menettäminen

Pääprojektissa ihmiset valmistautuivat isoon tapahtumaan. Keralan hallitus aikoo ilmoittaa pelastussivustolle julkisesti. Vilkasta liikennettä oli odotettavissa.

Pääsivusto tarjosi paljon toimintoja. Lämpökartat pyynnöistä, lahjoituksista, avustusleireistä, vapaaehtoistyön koordinoinnista, ilmoituksista, saat ydin.

Olen kehittänyt vakavaa kunnioitusta dev-ops-tiimiä kohtaan, koska kun liikenne osui sivustoon, he työskentelivät yön yli mitoittaakseen sitä.

Kaikki näytti toimivan, paitsi yksi asia: he ottivat pois API-päätepisteen, josta olin riippuvainen.

Nyt tiesin, että käyttämäni päätepiste ei aio mitoittaa. Se palautti kaikki pyynnöt kerralla. Elämänsä loppua kohti se palautti 10 Mt: n tietoaineiston. Se tehtiin kehitykseen eikä tuotannon käyttöön.

Onneksi sivustollani oli jo välimuistimekanismi, joten se pysyi toiminnassa.

Olen ottanut yhteyttä joukkueeseen. He rakensivat vaihtoehtoa. Mutta heillä oli paljon jäljellä rakentaa, joten yritin olla työntämättä.

Sivustoni jatkui toimimattomana, ja triatuuriryhmät (joita tässä vaiheessa oli useita) jatkoivat toimintaansa, vaikkakin ilman uutta tietoa.

Uudet ominaisuudet?

Tässä vaiheessa aloin miettiä tapoja parantaa.

Välitön ongelma oli suurten määrien uuden tiedon tulo, kun vaihtoehtoinen reitti tuli saataville. Ja mitä muita parannuksia voisin tehdä?

Ajattelin joitain piirteitä.

  • Aikaan perustuvat ryhmät: Määritä tietty prosenttiosuus käyttäjiä käsittelemään uusimpia pyyntöjä. Samoin määritä käyttäjät vanhempien pyyntöjen osioihin.
  • Kukkasuodattimet: Ne ovat tilaa säästävä tapa testata ryhmän jäsenyyttä. Voisin käyttää kukasuodattimia niin moniin asioihin: varmista, että olemme tyhjentäneet kaikki pyynnöt ja rajoita toistuvia käyntejä.
  • Tilapäivitykset: Voisin rakentaa ominaisuuden, jonka avulla ihmiset voivat päivittää pyyntöjen tilan. Se oli triviaalia, ja ihmiset vaativat sitä. Mutta pääalustalla työskentelevät ihmiset kertoivat minulle rakentavansa sitä jo.
  • Verkkokaupat: Voisin suoratoistaa uusia pyyntöjä verkkosivustolle reaaliajassa heidän saapuessaan. Yhdistettynä tilapäivityksiin ja aikakohortteihin, saimme yksityiskohtaisia ​​tietoja pyynnöistä heti, kun ne saapuvat.

Minulla oli paljon kilpailevia ideoita, enkä ollut varma, mitä voitaisiin toteuttaa ajoissa ollakseen hyödyllisiä.

Paketoida

API-päätepiste palasi seuraavana päivänä. Se sivistettiin nyt ja palasi 300 pyyntöä kerrallaan. Kirjoitin nopeasti komentosarjan paikallisen välimuistin lataamiseksi ja ylläpitämiseksi käyttämällä uutta sovellusliittymää.

Vastaanottamiesi puhelujen ja viestien määrä saavutti uuden korkeimman. Koska se ei ollut koskaan aiemmin ollut työssä, tämä oli uusi maasto. Pääalustalla työskentelevät DEV: t ottivat minuun yhteyttä. He työskentelivät integroidakseen joukkotietoihin perustuvia tietoja - sekä kiireellisyyden arviointeja että kerättyjä tilapäivityksiä.

Päivän päätyttyä triage-ryhmien ihmiset tunsivat muutoksen.

Suurin osa uhreista, joihin he soittivat, ilmoitti pelastavansa äskettäin. Osoittautuu, että kentällä olevat pelastustehtävät olivat alkaneet.

Tämä oli hieno uutinen. Noin kello 5.00 sain puhelun Nishanthin kanssa. Hän oli yhteydessä valtion virkamiehiin, jotka valvoivat pelastustoimia. Pakatimme tiedot verkkosivustolta ja laskentataulukoista ja luovutimme sen.

Tätä kirjoitettaessa tulvan uhrit on pelastettu ja kuljetettu avustusleireille. Uusia haasteita ovat logistiikka leirien välillä ja ympäri maata saatava apu.

Lessons

  • Yksinkertaisuus: Monet ihmiset viestivät minulle, että he pitivät sivustoltasi. En ole suunnittelija, mutta päätökseni pitää UX yksinkertaisena auttoi ihmisiä pääsemään alukseen nopeammin.
  • Tietojenkäsittely on halpaa: Kaikki tämä järjestettiin Google Cloud Platform -palvelussa. Se maksoi minulle alle dollarin, ja se sisältyy ilmaisiin omien luottojeni piiriin. Jos olisin tiennyt, kuinka halpaa se olisi, olisin rakentanut sovelluksen, joka on raskas taustalle.
  • Kääntö: Toivon, että kääntyisin täysin yksityiskohtaiseen triaatioalustaan. Vapaaehtoiset keksivät hätävaihtoratkaisun, mutta jälkikäteen olisin mieluummin lähettänyt alustaan ​​nämä ominaisuudet.
  • Verkostot ovat tärkeitä: Ihmiset halusivat auttaa. Alkuperäinen 30 ryhmä kasvoi kahden päivän aikana 230-ryhmäksi, kun ihmiset kutsuivat ystäviä ja tuttavia. Ihmiset liittyivät sisään Keralasta, muusta Intiasta ja ympäri maailmaa.

Olen tavannut monia uskomattomia ihmisiä. Olen oppinut paljon teknistä ja muuten. Kaiken tämän kautta uskomattomin tunne oli olla samalla sivulla tuhansien muiden ihmisten kanssa.

Jos työni ansaitsee artikkelin, projekti, johon kuulin, ansaitsee kirjan.

Mitä tulee minuun, otan yhteyttä ihmisiin, jotka osallistuvat katastrofivalmiuksiin oppiakseen heidän kokemuksestaan ​​ja asiantuntemuksestaan.

Hieman lisää minusta: Olen tekemässä aukon vuoden syventyäksesi salaustekniikkaan. Otin verkkokehitystaidot takaisin 10. luokassa isännöidessään hackathon-ohjelmaa koulussa.

Harkitsen tämän perusteella hankkeen kehittämistä, mutta monien muiden oivalluksien kanssa, jotka minulla ja ystävälläni ovat siitä lähtien olleet.

  • Annosteluryhmien vapaaehtoinen Ann Thomas kirjoitti kokemuksestaan ​​täällä
  • Kiitos tri Harikrishnanille, tohtori Nishanthille, Ajit Chandranille, Prasad Pillaille, jotka auttoivat järjestämään triaatioryhmiä