Ang paksa ng DevOps at IaC ay napakapopular at mabilis na umuunlad. Gayunpaman, karamihan sa mga may-akda ay humaharap sa puro teknikal na mga problema sa landas na ito. Ilalarawan ko ang mga problemang katangian ng isang malaking kumpanya. Wala akong solusyon - ang mga problema, sa pangkalahatan, ay nakamamatay at namamalagi sa lugar ng burukrasya, pag-audit, at "soft skills".
Dahil ang pamagat ng artikulo ay ganito, si Daenerys, na pumunta sa gilid ng Enterprise, ay gaganap bilang pusa.
Walang alinlangan, ngayon ay may banggaan ng luma at bago. At madalas sa mga banggaan na ito ay walang tama o mali. Nangyari lang yan. Ngunit, upang hindi maging walang batayan, magsisimula kami sa screen na ito:
Ito ang tinatawag na Change Request. Nakikita mo ang tungkol sa isang third ng mga patlang na kailangang punan mula sa iba't ibang mga direktoryo, ang natitirang mga patlang ay nasa iba pang mga bookmark. Ang nasabing dokumento ay dapat punan upang mailapat ang script sa production server, o mag-upload ng mga bagong file, o sa pangkalahatan ay magbago ng anuman.
Ang bilang ng mga patlang ay tulad na isinulat ko ang aking sariling maliit na automation para sa pagpuno sa mga patlang na ito. Bukod dito, ang pahinang ito ay isinulat sa paraang walang mga tool sa automation ang makakakita sa mga patlang nito, at ang tanging posibleng solusyon ay ang paggamit ng AutoIt upang walang tigil na mag-click sa mga coordinate gamit ang mouse. Tayahin ang iyong antas ng desperasyon na gawin ito:
Kaya, kukuha ka ng jenkins, chef, terraform, nexus, atbp., at masayang i-deploy ang lahat ng ito sa iyong dev. Ngunit dumating ang oras upang ipadala ito sa QA, UAT at PROD. Mayroon kang Nexus artifact at nakatanggap ka ng sulat mula sa DBA na may ganito:
mahal,
Una sa lahat, ang iyong koneksyon na maaari mong makuha para sa iyong sarili Wala akong access sa iyong Nexus
Pangalawa, ang lahat ng mga pagbabago ay dapat ibigay bilang isang Kahilingan sa Pagbabago.
Kailangan mong kunin ang mga SQL script mula sa Nexus at ilakip ang mga ito sa Kahilingan sa Pagbabago.
Kung hindi Emergency ang pagbabago, dapat itong gawin 7 araw bago i-release (eksklusibo sa Weekend)
Kapag ang iyong Kahilingan sa Pagbabago ay naaprubahan ng isang grupo ng mga tao, isasagawa ng DBA ang iyong script at magpapadala pa nga ng screenshot ng resulta sa pamamagitan ng koreo.Pinakamahusay na pagbati, ang iyong DBA na nagtatrabaho dito mula noong mga araw ng mainframe.
Alam mo ba kung ano ang nagpapaalala sa akin? Semi-automation: hawak ng robot ang frame, at hinampas ito ng manggagawa ng sledgehammer. Well, talaga, ano ang silbi ng Nexus na ito kung ang lahat ay ganap na gagawin nang manu-mano?
Ngunit hindi dapat sisihin ang Enterprise para dito! Siyempre, madugo, ngunit ang lahat ng burukrasya na ito na may mga Kahilingan sa Pagbabago ay pinilit at nagmumula sa mga auditor. Ang negosyo ay dapat gumana sa ganitong paraan, panahon. Wala siyang magagawa sa ibang paraan. At ang pag-audit ay isang napakakonserbatibong bagay. Halimbawa, kung gaano karami ang nasabi tungkol sa katotohanan na masama ang mahabang pseudo-complex at madalas na pagbabago ng mga password, ngunit ang mga negosyo ang huling lugar kung saan ito babaguhin. Gayundin sa mga deployment at lahat ng iba pa.
Sa pamamagitan ng paraan, sa isang pagkakataon sinubukan kong lumikha ng isang file para sa terraform, ngunit hindi ito gumana. Natisod ako sa kahulugan ng tag na 'Project Accounting Billing Code', na hindi ko nalaman - wala akong sapat na soft skills.
Hindi man lang ako kumukuha sa paksa ng passive Luddism - naku, ang iyong automation ay nagbabanta sa aking seguridad sa trabaho, ayaw kong matuto ng bago, kaya tahimik kong sasabotahe ito.
Well, ano ang maaaring maging solusyon sa prinsipyo? Ang ITSM system ay may napaka-primitive na API para sa awtomatikong pagbuo ng mga dokumento. At sa pangkalahatan, karamihan sa mga sistemang ito ay nagmula sa mga panahon ng mga mainframe. Mayroon bang nakakaalam ng anumang tunay na modernong mga sistema ng ITSM? Mayroon bang matagumpay na karanasan sa pagsasama ng modernong DevOps at burukrasya? Siyempre, hindi natin pinag-uusapan ang puro mga site ng pagbebenta, kung saan maaaring magkaroon ng deployment araw-araw, ngunit, halimbawa, ang sektor ng pagbabangko, na nasa ilalim ng mga auditor at napakalakas na paghihiwalay sa mas mataas na kapaligiran.
Huwag lamang kalimutan na ang lahat ng iyong mga pantasya ay limitado ng pag-audit. At iyon ang nagbabago sa lahat. Hihintayin kita sa mga komento!
Pinagmulan: www.habr.com