Nag-uusap kami, siyempre, tungkol sa . Kung hindi ka pumunta sa mga detalye, pagkatapos ay sa Setyembre 30 at Oktubre 1 ay gaganapin namin ang isang kumperensya sa pagsasama-sama ng mga proseso ng pag-unlad, pagsubok at operasyon, at kung pupunta ka sa mga detalye, mangyaring, sa ilalim ng pusa.
Bilang bahagi ng diskarte sa DevOps, ang lahat ng bahagi ng teknolohikal na pag-unlad ng isang proyekto ay magkakaugnay, nangyayari nang magkatulad at nakakaimpluwensya sa isa't isa. Ang partikular na kahalagahan dito ay ang paglikha ng mga automated na proseso ng pag-unlad na maaaring baguhin, kunwa at subukan sa real time. Tinutulungan ka nitong tumugon kaagad sa mga pagbabago sa merkado.
Sa kumperensya gusto naming ipakita kung paano nakakaimpluwensya ang diskarte na ito sa pagbuo ng produkto. Paano tinitiyak ang pagiging maaasahan at kakayahang umangkop ng system para sa kliyente. Paano binabago ng DevOps ang istraktura at diskarte ng isang kumpanya sa pag-aayos ng proseso ng trabaho nito.
sa likod ng kamera
Mahalagang malaman natin hindi lamang kung ano ang ginagawa ng iba't ibang kumpanya sa loob ng balangkas ng diskarte sa DevOps, ngunit upang maunawaan din kung bakit ginagawa ang lahat ng ito. Samakatuwid, inimbitahan namin hindi lamang ang mga eksperto na sumali sa Komite ng Programa, ngunit ang mga espesyalista na nakakakita ng diskurso ng DevOps mula sa iba't ibang posisyon:
- matatandang inhinyero;
- mga developer;
- nangunguna sa pangkat;
- CTO.
Sa isang banda, lumilikha ito ng mga paghihirap at salungatan kapag tinatalakay ang mga kahilingan para sa mga ulat. Kung interesado ang isang engineer sa pagsusuri ng isang malaking aksidente, mas mahalaga para sa isang developer na maunawaan kung paano gumawa ng software na gumagana sa mga ulap at imprastraktura. Ngunit sa pamamagitan ng pagsang-ayon, lumikha kami ng isang programa na magiging mahalaga at kawili-wili sa lahat: mula sa mga inhinyero hanggang sa CTO.
Ang layunin ng aming kumperensya ay hindi lamang upang piliin ang pinakamaraming ulat ng hype, ngunit upang ipakita ang pangkalahatang larawan: kung paano gumagana ang diskarte sa DevOps sa pagsasanay, kung anong uri ng rake ang maaari mong matamo kapag lumipat sa mga bagong proseso. Kasabay nito, binubuo namin ang bahagi ng nilalaman, pababa mula sa problema sa negosyo patungo sa mga partikular na teknolohiya.
Ang mga seksyon ng kumperensya ay mananatiling pareho sa .
- Platform ng imprastraktura.
- Imprastraktura bilang code.
- Tuloy-tuloy na paghahatid.
- Feedback.
- Arkitektura sa DevOps, DevOps para sa CTO.
- Mga kasanayan sa SRE.
- Pagsasanay at pamamahala ng kaalaman.
- Seguridad, DevSecOps.
- Pagbabago ng DevOps.
Call for Papers: anong uri ng mga ulat ang hinahanap namin
May kondisyon kaming hinati ang potensyal na madla ng kumperensya sa limang grupo: mga inhinyero, developer, mga espesyalista sa seguridad, mga pinuno ng koponan at CTO. Bawat grupo ay may kanya-kanyang motibasyon na dumalo sa kumperensya. At, kung titingnan mo ang DevOps mula sa mga posisyong ito, mauunawaan mo kung paano ituon ang iyong paksa at kung saan ilalagay ang diin.
Para sa mga inhinyero, na lumilikha ng isang platform sa imprastraktura, mahalagang maunawaan ang mga kasalukuyang uso, upang maunawaan kung aling mga teknolohiya ang pinaka-advanced na ngayon. Magiging interesado silang matuto tungkol sa totoong buhay na karanasan sa paggamit ng mga teknolohiyang ito at pagpapalitan ng opinyon. Ang isang engineer ay magiging masaya na makinig sa isang ulat na nagsusuri ng ilang hardcore na aksidente, at kami naman, ay susubukan na pumili at pakinisin ang naturang ulat.
Para sa mga developer mahalagang maunawaan ang ganitong konsepto bilang cloud native na application. Iyon ay, kung paano bumuo ng software upang ito ay gumana sa mga ulap at iba't ibang mga imprastraktura. Kailangang patuloy na makatanggap ang developer ng feedback mula sa software. Dito gusto naming marinig ang mga kaso tungkol sa kung paano binuo ng mga kumpanya ang prosesong ito, kung paano subaybayan ang pagganap ng software, at kung paano gumagana ang buong proseso ng paghahatid.
Mga espesyalista sa cybersecurity Mahalagang maunawaan kung paano i-set up ang proseso ng seguridad upang hindi matigil ang pag-unlad at pagbabago ng mga proseso sa loob ng kumpanya. Magiging interesante din ang mga paksa tungkol sa mga kinakailangan na inilalagay ng DevOps sa mga naturang espesyalista.
Nais malaman ng mga pinuno ng koponan, kung paano gumagana ang tuluy-tuloy na proseso ng paghahatid sa ibang mga kumpanya. Anong landas ang tinahak ng mga kumpanya upang makamit ito, paano sila bumuo ng mga proseso ng pag-unlad at pagtiyak ng kalidad sa loob ng DevOps. Interesado din ang mga lead ng team sa Cloud native. At pati na rin ang mga tanong tungkol sa pakikipag-ugnayan sa loob ng team at sa pagitan ng development at engineering team.
Para sa CTO ang pinakamahalagang bagay ay upang malaman kung paano ikonekta ang lahat ng mga prosesong ito at iakma ang mga ito sa mga pangangailangan ng negosyo. Tinitiyak niya na ang application ay maaasahan para sa negosyo at sa kliyente. At dito kailangan mong maunawaan kung aling mga teknolohiya ang gagana para sa kung aling mga gawain sa negosyo, kung paano buuin ang buong proseso, atbp. Ang CTO ay responsable din sa pagbabadyet. Halimbawa, dapat niyang maunawaan kung gaano karaming pera ang kailangang gastusin sa mga espesyalista sa muling pagsasanay upang makapagtrabaho sila sa DevOps.
Kung mayroon kang sasabihin tungkol sa mga bagay na ito, huwag manatiling tahimik, . Ang deadline para sa Call for Papers ay ika-20 ng Agosto. Kung mas maaga kang magparehistro, mas maraming oras ang kakailanganin mong tapusin ang iyong ulat at maghanda para sa iyong presentasyon. Kaya, huwag mag-antala.
Well, kung hindi mo kailangang magsalita sa publiko, basta at darating sa Setyembre 30 at Oktubre 1 upang makipag-usap sa mga kasamahan. Ipinapangako namin na ito ay magiging kawili-wili at nagbibigay-inspirasyon.
Paano natin nakikita ang DevOps
Upang maunawaan nang eksakto kung ano ang ibig sabihin ng DevOps, inirerekomenda kong basahin (o muling basahin) ang aking ulat "" Sa paglalakad sa mga alon ng merkado, napagmasdan ko kung paano nagbabago ang ideya ng DevOps sa iba't ibang laki ng mga kumpanya: mula sa isang maliit na startup hanggang sa mga multinational na kumpanya. Ang ulat ay binuo sa isang serye ng mga tanong, sa pamamagitan ng pagsagot sa mga ito ay mauunawaan mo kung ang iyong kumpanya ay patungo sa DevOps o kung may mga problema sa isang lugar.
Ang DevOps ay isang kumplikadong sistema, dapat itong kasama ang:
- Digital na produkto.
- Mga module ng negosyo na bumuo ng digital na produktong ito.
- Mga pangkat ng produkto na nagsusulat ng code.
- Patuloy na Paghahatid ng mga kasanayan.
- Mga platform bilang isang serbisyo.
- Imprastraktura bilang isang serbisyo.
- Imprastraktura bilang code.
- Paghiwalayin ang mga kasanayan para sa pagpapanatili ng pagiging maaasahan, na binuo sa DevOps.
- Isang kasanayan sa feedback na naglalarawan sa lahat ng ito.
Sa dulo ng ulat mayroong isang diagram na nagbibigay ng ideya ng sistema ng DevOps sa kumpanya. Bibigyang-daan ka nitong makita kung aling mga proseso sa iyong kumpanya ang na-streamline na at kung alin pa ang gagawin.
Maaari mong panoorin ang video ng ulat .
At ngayon magkakaroon ng bonus: ilang mga video mula sa RIT++ 2019, na nakakaapekto sa mga pinaka-pangkalahatang isyu ng pagbabagong DevOps.
Imprastraktura ng kumpanya bilang isang produkto
Pinamunuan ni Artyom Naumenko ang DevOps team sa Skyeng at pinangangasiwaan ang pagbuo ng imprastraktura ng kanyang kumpanya. Sinabi niya kung paano nakakaapekto ang imprastraktura sa mga proseso ng negosyo sa SkyEng: kung paano kalkulahin ang ROI para dito, anong mga sukatan ang dapat piliin para sa pagkalkula at kung paano magtrabaho upang mapabuti ang mga ito.
Sa daan patungo sa mga microservice
Ang kumpanya ng Nixys ay nagbibigay ng suporta para sa mga abalang proyekto sa web at mga distributed system. Ang teknikal na direktor nito, si Boris Ershov, ay nagsabi kung paano isalin ang mga produkto ng software, ang pag-unlad nito ay nagsimula 5 taon na ang nakakaraan (o higit pa), sa isang modernong platform.
Bilang isang patakaran, ang mga naturang proyekto ay isang espesyal na mundo kung saan may mga madilim at sinaunang sulok ng imprastraktura na hindi alam ng mga kasalukuyang inhinyero tungkol sa kanila. At ang mga diskarte sa arkitektura at pag-unlad na dating napili ay luma na at hindi makapagbibigay sa negosyo ng parehong bilis ng pag-unlad at pagpapalabas ng mga bagong bersyon. Bilang resulta, ang bawat paglabas ng produkto ay nagiging isang hindi kapani-paniwalang pakikipagsapalaran, kung saan ang isang bagay ay patuloy na nahuhulog, at sa pinaka hindi inaasahang lugar.
Ang mga tagapamahala ng naturang mga proyekto ay hindi maiiwasang nahaharap sa pangangailangan na baguhin ang lahat ng mga teknolohikal na proseso. Sa kanyang ulat, sinabi ni Boris:
- kung paano pumili ng tamang arkitektura para sa proyekto at ayusin ang imprastraktura;
- anong mga tool ang gagamitin at anong mga pitfalls ang nararanasan sa landas tungo sa pagbabago;
- kung ano ang susunod na gagawin.
Automation ng mga release o kung paano maghatid ng mabilis at walang sakit
Si Alexander Korotkov ay isang nangungunang developer ng CI/CD system sa CIAN. Nagsalita siya tungkol sa mga tool sa automation na naging posible upang mapabuti ang kalidad at bawasan ang oras para sa paghahatid ng code sa produksyon ng 5 beses. Ngunit ang gayong mga resulta ay hindi makakamit sa automation lamang, kaya binigyang pansin din ni Alexander ang mga pagbabago sa mga proseso ng pag-unlad.
Paano ka natutulungan ng mga aksidente na matuto?
Si Alexey Kirpichnikov ay nagpapatupad ng DevOps at imprastraktura sa SKB Kontur sa loob ng 5 taon. Sa loob ng tatlong taon, humigit-kumulang 1000 fakap ng iba't ibang antas ng epicness ang naganap sa kanyang kumpanya. Kabilang sa mga ito, halimbawa, 36% ay sanhi ng paglulunsad ng isang mababang kalidad na release sa produksyon, at 14% ay sanhi ng hardware maintenance work sa data center.
Ang isang archive ng mga ulat (post-mortems) na pinapanatili ng mga inhinyero ng kumpanya sa loob ng ilang magkakasunod na taon ay ginagawang posible na makakuha ng tumpak na impormasyon tungkol sa mga aksidente. Ang post-mortem ay isinulat ng engineer na naka-duty, na siyang unang tumugon sa emergency signal at nagsimulang ayusin ang lahat. Bakit pinapahirapan ang mga inhinyero na nakikipagpunyagi sa gabi sa pamamagitan ng pagsusulat ng mga ulat? Nagbibigay-daan sa iyo ang data na ito na makita ang buong larawan at ilipat ang pagbuo ng imprastraktura sa tamang direksyon.
Sa kanyang talumpati, ibinahagi ni Alexey kung paano magsulat ng isang tunay na kapaki-pakinabang na postmortem at kung paano ipatupad ang pagsasagawa ng mga naturang ulat sa isang malaking kumpanya. Kung mahilig ka sa mga kwento tungkol sa kung paano niloko ng isang tao, panoorin ang video ng pagganap.
Naiintindihan namin na ang iyong pananaw sa DevOps ay maaaring hindi tumugma sa amin. Magiging kawili-wiling malaman kung paano mo nakikita ang pagbabago ng DevOps. Ibahagi ang iyong karanasan at pananaw sa paksang ito sa mga komento.
Anong mga ulat ang tinanggap na natin sa programa?
Sa linggong ito ang Komite ng Programa ay nagpatibay ng 4 na ulat: sa seguridad, imprastraktura at mga kasanayan sa SRE.
Marahil ang pinakamasakit na paksa ng pagbabagong-anyo ng DevOps: kung paano tiyakin na ang mga lalaki mula sa departamento ng seguridad ng impormasyon ay hindi sirain ang mga nakagawa nang koneksyon sa pagitan ng pag-unlad, operasyon at pangangasiwa. Ang ilang mga kumpanya ay namamahala nang walang departamento ng seguridad ng impormasyon. Paano masisiguro ang seguridad ng impormasyon sa kasong ito? Tungkol doon Mona Arkhipova mula sa sudo.su. Mula sa kanyang ulat natutunan natin:
- ano ang kailangang protektahan at kanino;
- ano ang mga nakagawiang proseso ng seguridad;
- kung paano nagsalubong ang mga proseso ng IT at seguridad ng impormasyon;
- ano ang CIS CSC at kung paano ito ipatupad;
- paano at sa anong mga tagapagpahiwatig ang magsagawa ng mga regular na pagsusuri sa seguridad ng impormasyon.
Ang susunod na ulat ay tungkol sa pagbuo ng imprastraktura bilang code. Bawasan ang dami ng manu-manong gawain at huwag gawing gulo ang buong proyekto, posible ba ito? Sa tanong na ito Maxim Kostrikin mula sa Ixtens. Ginagamit ng kanyang kumpanya Terraform para sa pagtatrabaho sa imprastraktura ng AWS. Ang tool ay maginhawa, ngunit ang tanong ay kung paano maiwasan ang paglikha ng isang malaking bloke ng code kapag ginagamit ito. Ang pagpapanatili ng naturang legacy ay magiging mas at mas mahal bawat taon.
Ipapakita ng Maxim kung paano gumagana ang mga pattern ng paglalagay ng code, na naglalayong pasimplehin ang automation at development.
Isa pa maririnig natin ang tungkol sa imprastraktura mula sa Vladimir Ryabov mula sa Playkey. Dito natin pag-uusapan ang platform ng imprastraktura, at matututuhan natin:
- kung paano maunawaan kung ang espasyo sa imbakan ay epektibong ginagamit;
- kung paano makakatanggap ang ilang daang user ng 10 TB ng content kung 20 TB lang ng storage ang gagamitin;
- kung paano i-compress ang data ng 5 beses at ibigay ito sa mga user nang real-time;
- kung paano i-synchronize ang data sa mabilisang pagitan ng ilang mga data center;
- kung paano alisin ang anumang impluwensya ng mga gumagamit sa isa't isa kapag gumagamit ng isang virtual machine nang sunud-sunod.
Ang sikreto ng magic na ito ay teknolohiya ZFS para sa FreeBSD at ang sariwang tinidor nito ZFS sa Linux. Magbabahagi si Vladimir ng mga kaso mula sa Playkey.
Matvey Kukuy mula sa Amixr.IO handa sa mga halimbawa mula sa buhay , anong nangyari SRE at kung paano ito nakakatulong sa pagbuo ng mga mapagkakatiwalaang sistema. Ipinapasa ng Amixr.IO ang mga insidente ng kliyente sa pamamagitan ng backend nito; dose-dosenang mga on-duty na team sa buong mundo ang nakaharap na sa 150 libong kaso. Sa kumperensya, ibabahagi ni Matvey ang mga istatistika at mga insight na naipon ng kanyang kumpanya sa pamamagitan ng paglutas ng mga problema ng customer at pagsusuri ng mga pagkabigo.
Muli kong hinihimok ka na huwag maging sakim at ibahagi ang iyong karanasan bilang isang DevOps samurai. maglingkod para sa isang ulat, at ikaw at ako ay magkakaroon ng 2,5 buwan upang maghanda ng isang mahusay na pagtatanghal. Kung gusto mong maging tagapakinig, sa newsletter na may mga update sa programa at seryosong isipin ang tungkol sa pag-book ng mga tiket nang maaga, dahil magiging mas mahal ang mga ito nang mas malapit sa mga petsa ng kumperensya.
Pinagmulan: www.habr.com