د DevOps او IaC موضوع خورا مشهوره ده او په چټکۍ سره وده کوي. په هرصورت، ډیری لیکوالان د دې لارې په اوږدو کې د خالص تخنیکي ستونزو سره معامله کوي. زه به د لوی شرکت ځانګړتیاوې تشریح کړم. زه د حل لاره نلرم - ستونزې، په عموم کې، وژونکي دي او د بیوروکراسي، پلټنې، او "نرم مهارتونو" په ساحه کې دروغ دي.
څرنګه چې د مقالې سرلیک داسې دی، ډینیریز، چې د شرکت لوري ته تللی، د پیشو په توګه به عمل وکړي.
بې له شکه اوس د زړو او نویو ټکر دی. او اکثرا په دې ټکرونو کې نه سم وي او نه غلط. همداسې وشول. مګر، د دې لپاره چې بې بنسټه نه وي، موږ به د دې سکرین سره پیل وکړو:
دا د تش په نامه بدلون غوښتنه ده. تاسو د ساحو دریمه برخه ګورئ چې اړتیا لري د مختلف لارښودونو څخه ډک شي ، پاتې ساحې په نورو بک مارکونو کې دي. دا ډول سند باید ډک شي ترڅو سکریپټ د تولید سرور ته پلي کړي، یا نوي فایلونه اپلوډ کړي، یا په عمومي توګه هر څه بدل کړي.
د ساحو شمیر دومره دی چې ما د دې ساحو ډکولو لپاره خپل کوچني اتومات لیکلی. سربیره پردې ، دا پاڼه په داسې ډول لیکل شوې چې هیڅ اتومات وسیلې نشي کولی د هغې ساحې وګوري ، او یوازینۍ ممکنه حل د AutoIt کارولو لپاره و چې د موږک سره همغږي باندې کلیک وکړئ. د دې کولو لپاره ستاسو د نا امیدۍ کچه ارزونه وکړئ:
نو، تاسو جینکنز، شیف، ټرافورم، نیکسس، او نور واخلئ، او په خوښۍ سره دا ټول خپل دیو ته ځای په ځای کړئ. مګر وخت راځي چې دا QA، UAT او PROD ته واستوي. تاسو د Nexus هنري اثار لرئ او تاسو د DBA څخه د دې په څیر یو لیک ترلاسه کوئ:
ګرانه
تر ټولو لومړی، ستاسو Nexus تاسو کولی شئ د ځان لپاره ولرئ زه ستاسو Nexus ته لاسرسی نلرم
دوهم، ټول بدلونونه باید د بدلون غوښتنې په توګه صادر شي.
تاسو اړتیا لرئ له Nexus څخه د SQL سکریپټونه راوباسئ او د بدلون غوښتنې سره یې ضمیمه کړئ.
که بدلون بیړنی نه وي، دا باید د خوشې کیدو څخه 7 ورځې مخکې ترسره شي (په ځانګړې توګه د اونۍ په پای کې)
کله چې ستاسو د بدلون غوښتنه د ډیری خلکو لخوا تصویب شي ، DBA به ستاسو سکریپټ اجرا کړي او حتی د بریښنالیک له لارې به د پایلې سکرین شاټ واستوي.په زړه پوری ، ستاسو DBA څوک چې د مین فریم ورځو راهیسې دلته کار کوي.
ایا تاسو پوهیږئ چې دا ما څه یادوي؟ نیمه اتوماتیک: روبوټ چوکاټ ساتي، او کارګر یې د سلیج هامر سره وهي. ښه ، واقعیا ، د دې Nexus څه معنی لري که بیا هرڅه په بشپړ ډول په لاسي ډول ترسره شي؟
مګر شرکت باید د دې لپاره ملامت نه شي! دا، البته، خونړۍ ده، مګر دا ټول بیوروکراسي د بدلون غوښتنې سره مجبور دي او د پلټونکو لخوا راځي. شرکت باید په دې ډول کار وکړي، موده. هغه دا په بله لاره نه شي کولی. او پلټنه یو ډیر محافظه کار شی دی. د مثال په توګه ، د دې حقیقت په اړه څومره ویل شوي چې اوږد سیډو - پیچلي او په مکرر ډول بدل شوي پاسورډونه خراب دي ، مګر تصدۍ به وروستی ځای وي چیرې چې دا به بدل شي. همدارنګه د ګمارنې او هر څه سره.
په لاره کې، په یو وخت کې ما هڅه وکړه چې د ټرافورم لپاره فایل جوړ کړم، مګر دا کار ونه کړ. ما د 'پروژې د حساب ورکولو بلینګ کوډ' ټاګ معنی ته مخه کړه، کوم چې ما هیڅکله نه دی موندلی - زه کافي نرم مهارتونه نه لرم.
زه حتی د غیر فعال لوډیزم موضوع نه اخلم - اوه ، ستاسو اتومات زما د دندې امنیت ګواښي ، زه نه غواړم کوم نوی زده کړم ، نو زه به یې په خاموشۍ سره تخریب کړم.
ښه، په اصولو کې د حل لاره څه کېدای شي؟ د ITSM سیسټم په اتوماتيک ډول د اسنادو تولید لپاره خورا ابتدايي API لري. او په عموم کې، ډیری دا سیسټمونه د مین فریمونو وخت څخه راځي. ایا څوک د ریښتیا عصري ITSM سیسټمونه پیژني؟ ایا څوک د عصري DevOps او بیوروکراسي ادغام بریالۍ تجربه لري؟ البته موږ د خالص پلور سایټونو په اړه خبرې نه کوو ، چیرې چې واقعیا هره ورځ ګمارل کیدی شي ، مګر د مثال په توګه ، د بانکدارۍ سکتور چې د پلټونکو لاندې دی او په لوړو چاپیریالونو کې خورا قوي انزوا دی.
یوازې مه هیروئ چې ستاسو ټول تصورات د پلټنې لخوا محدود دي. او دا هرڅه بدلوي. زه ستاسو په نظرونو کې انتظار کوم!
سرچینه: www.habr.com