DevOps немесе біз жалақыны қалай жоғалтып жатқанымыз және IT индустриясының болашағы

Бүгінгі жағдайдағы ең өкініштісі, IT бірте-бірте адамға шаққандағы міндеттер санында «тоқтату» деген сөз жоқ салаға айналуда.

Бос жұмыс орындарын оқығанда, кейде сіз бір адамнан 2-3 адамды емес, тұтас компанияны көресіз, барлығы асығыс, техникалық қарыз өсіп келеді, жаңа өнімдердің фонында ескі мұра кемелдікке ұқсайды, өйткені кем дегенде ол бар. кодтағы доктар мен түсініктемелер, жаңа өнімдер жарық жылдамдығымен жазылады, бірақ соңында олар жазылғаннан кейін тағы бір жыл бойы пайдаланыла алмайды және көбінесе биылғы жылы пайда әкелмейді; сонымен қатар «бұлт» шығындары ” қызмет сатылымынан жоғары. Инвесторлардың ақшасы әлі жұмыс істемейтін, бірақ жұмыс ретінде онлайн режимінде шығарылған қызметті қолдауға жұмсалады.
Мысал ретінде: ескі ойынның ремастері саланың бүкіл тарихындағы ең төмен рейтингтерге ие болған танымал компания. Мен бұл өнімді сатып алғандардың бірі болдым, бірақ қазірдің өзінде бұл өнім өте жақсы жұмыс істейді, және теориялық тұрғыдан ол мұндай формада сатылмауы керек еді. Қайтарулар, рейтингтердің төмендеуі, қызметтердің жұмысына шағымдану үшін форумдардағы пайдаланушылардың көптеген тыйымдары. Патчтардың саны таңқаларлық емес, бірақ қорқынышты, бірақ бәрібір өнім қолдануға жарамсыз. Бұл тәсіл 91 жылдан бері дамып келе жатқан компания үшін осындай нәтижелерге әкелетін болса, енді ғана жұмысын бастаған компаниялар үшін жағдай одан да қиын.

Бірақ біз бұл тәсілдің нәтижелерін қызмет пайдаланушысы жағынан қарадық, ал енді қызметкерлер кездескен мәселелерді қарастырайық.

Мен DevOps командалары болмауы керек деген мәлімдемені жиі естимін, бұл әдістеме және т. . Әрине, жекелеген компанияларда мұндай бос орындар әлі де бар, бірақ олардың саны азайып барады. Көбісі бұл даму деп атады, мен жеке деградацияны көремін, барлық салада жақсы білім деңгейін ұстап тұру мүмкін емес, сонымен бірге 8 сағаттан аспайтын жұмыс істей алады. Әрине, бұл қиял. Шындығында, көптеген IT қызметкерлері 12 немесе 14 сағат жұмыс істеуге мәжбүр, оның 8-і төленеді.Көбінесе демалыс күндері болмайды, өйткені «маған тапсырма берілді, құжаттар жоқ немесе қисық, ал қызмет ақшаға кетеді» және бұлттағы 1 қателік үшін сіз негізінен бір-екі айда жалақы ала алмайсыз, әсіресе жеке кәсіпкер ретінде жұмыс істесеңіз. Біз жауапкершілікті бөлумен қатар бизнесте өз сөзімізді жоғалтып жатырмыз; Мен менеджерлердің даму процестеріне олар туралы ештеңе түсінбестен араласатыны, бизнес деректері мен қолданбаның жұмысын шатастыратын фактісімен жиі бетпе-бет келемін. нәтижесінде хаос басталады.

Хаос басталған кезде бизнес кінәліні тапқысы келеді және бұл жерде оларға әмбебап кінәлі керек; кінәні 10+ адамға жүктеу қиын, сондықтан менеджерлер позицияларды біріктіреді, өйткені бір маманның жауапкершілігі неғұрлым көп болса, соғұрлым оңайырақ болады. оның салғырттығын дәлелдеді. Ал Agile жағдайында «кінәлілерді» тауып, сабау менеджменттегі бизнесті жүргізудің осы әдістемесінің негізі болып табылады. Agile IT-дан баяғыда шықты, оның негізгі тұжырымдамасы күнделікті нәтиженің талабына айналды. Мәселе мынада, жоғары мамандандырылған маман әрқашан күнделікті нәтижелерге ие бола бермейді, бұл есеп беру қиынырақ болады дегенді білдіреді және бұл бизнестің «барлығы бойынша сарапшыларды» қалайтынының тағы бір себебі. Бірақ басты себеп, әрине, жалақы қоры - бұл барлық өзгерістердің негізгі себебі, бонус үшін адамдар өздеріне және сол жігітке жұмыс істеуге келісті. Бірақ, сайып келгенде, басқа салалардағы сияқты, бұл енді ұсынылатын қызметтердің көп саны үшін аз төлем үшін жауапкершілікке айналды.

Қазіргі уақытта сіз әзірлеушілер де орналастыруға қабілетті болуы керек, DevOps инженерімен бірге инфрақұрылымда жұмыс істеуі керек деген мақалаларды жиі көре аласыз, бірақ бұл не әкеледі? Бұл дұрыс - қызмет көрсету сапасының төмендеуіне, әзірлеушілердің сапасының төмендеуіне. Небәрі 2 күн бұрын әзірлеушіге әр түрлі хосттардан жазуға және оқуға болатынын түсіндірдім, олар мұндайды ешқашан көрмегенін дәлелдеу үшін аузынан көбік шығарды, бірақ параметрлерде orm host, port, db, user бар. , пароль және осымен…. Бірақ әзірлеуші ​​қолдануды іске қосуды, yam жазуды біледі... Бірақ ол кодтағы бірлік сынақтары мен түсініктемелерді ұмытып кетеді.

Соның нәтижесінде біз мынаны көреміз – үнемі үстеме жұмыс, жұмыстан тыс уақытта туындаған мәселелердің шешімін іздеу, демалыс күндері үнемі жаттығу және кірісті көбейту емес, өзімізді өзімізді ұстау. Әзірлеушілер DevOps инженеріне CI/CD-мен көмектесуге мәжбүр, ал егер әзірлеушінің уақыты болмаса, ол кептеліп қалады, ал менеджерлер олардың миын компосттай бастайды және бұл артық жұмыс істеуге деген құлшынысын арттыруға көмектеспесе, содан кейін айыппұлдар мен айыппұлдарды қолданады, адам Эверест көлеміндей техникалық қарызды қалдырып, жаңа жұмыс іздейді, нәтижесінде құрылыс салушылар арасында қарыз өсе бастайды, өйткені олар ескі немесе жаңа DevOps инженеріне көмектесуге уақыт табу үшін азырақ рефакторингпен код жазуға мәжбүр, ал менеджерлер бәріне риза, өйткені кінәлі сол жерде және оны бірден көруге болады, бұл негізгі ережені білдіреді Agile-де менеджмент орындалды, кінәлі табылды, оны қамшылаудың нәтижесі көрініп тұр.

Мен бір рет ITGM-де «біз «жоқ» деп айтуды үйренген кезде» презентациясын өткіздім - оның нәтижелері өте айқын болды. Көптеген адамдар бұл сөзді тыйым салынған деп санайды, және біз бұлай ойлауды тоқтатқанша, проблемалар тек өсе береді.

Бұл мақала ішінара мені шабыттандырды Бұл мақала, бірақ кейінірек мен оны сыпайы түрде сипаттай аламын.

Сауалнамаға тек тіркелген пайдаланушылар қатыса алады. Кіру, өтінемін.

Жұмыс беруші сізбен бірнеше адамды ауыстыруға тырысқан кезде жұмыста кездестіңіз бе?

• 65,6%Иә, мен оны үнемі кездестіремін183

• 5,4%Иә, оны 1 рет кездестірдім15

• 15,4%Байқамадым43

• 13,6%Мен жұмысшымын, өзім қосымша жұмыс істеймін38

279 пайдаланушы дауыс берді. 34 пайдаланушы қалыс қалды.

Ақпарат көзі: www.habr.com