నేను ఇటీవల Logrocon హోస్ట్ చేసిన DevOpsForum 2019కి హాజరయ్యాను. ఈ సమావేశంలో, పాల్గొనేవారు వ్యాపారం మరియు అభివృద్ధి మరియు సమాచార సాంకేతిక సేవా నిపుణుల మధ్య సమర్థవంతమైన పరస్పర చర్య కోసం పరిష్కారాలు మరియు కొత్త సాధనాలను కనుగొనడానికి ప్రయత్నించారు.
సమావేశం విజయవంతమైంది: నిజంగా చాలా ఉపయోగకరమైన నివేదికలు, ఆసక్తికరమైన ప్రెజెంటేషన్ ఫార్మాట్‌లు మరియు స్పీకర్లతో చాలా కమ్యూనికేషన్ ఉన్నాయి. మరియు పెద్ద సమావేశాలలో మాట్లాడేవారు ఈ మధ్యకాలంలో దోషులుగా ఉండేలా ఎవరూ నాకు ఏదైనా విక్రయించడానికి ప్రయత్నించకపోవడం చాలా ముఖ్యం.
Raiffeisenbank, Alfastrakhovanie, మ్యాంగో టెలికాం యొక్క ఆటోమేషన్‌ని అమలు చేయడంలో అనుభవం మరియు ఇతర వివరాలను కట్‌ కింద ప్రసంగాల నుండి ఒక సారాంశం.
నా పేరు యానా, నేను టెస్టర్‌గా పని చేస్తున్నాను, నేను ఆటోమేషన్ చేస్తాను, అలాగే DevOps చేస్తాను మరియు సమావేశాలు మరియు సమావేశాలకు వెళ్లడం నాకు చాలా ఇష్టం. గత రెండు సంవత్సరాలుగా, నేను ఒలేగ్ బునిన్ కాన్ఫరెన్స్‌లకు (హైలోడ్++, టీమ్‌లీడ్ కాన్ఫ్), జగ్ ఈవెంట్‌లు (హైసెన్‌బగ్, JPoint), టెస్ట్‌కాన్ మాస్కో, DevOps ప్రో మాస్కో, బిగ్ డేటా మాస్కోకు వెళ్లాను.
అన్నింటిలో మొదటిది, నేను సమావేశ కార్యక్రమానికి దృష్టిని ఆకర్షిస్తాను. నేను రిపోర్ట్ దేనికి సంబంధించినది అని తక్కువగా చూస్తున్నాను మరియు స్పీకర్ వద్ద ఎక్కువగా చూస్తాను. నివేదిక చాలా సాంకేతికంగా మరియు ఆసక్తికరంగా మారినప్పటికీ, మీరు మీ కంపెనీలో నివేదిక నుండి కొన్ని ఉత్తమ పద్ధతులను వర్తింపజేయగలరన్నది వాస్తవం కాదు. ఆపై మీకు స్పీకర్ కావాలి.
రైఫీసెన్‌బ్యాంక్ వద్ద పైప్లైన్ చివరిలో లైట్
సాధారణంగా, నాకు ఆసక్తి ఉన్న సైడ్‌లైన్‌లలో నేను స్పీకర్ల కోసం వేటాడతాను. DevOpsForum 2019లో, Raiffeisenbank నుండి ఒక స్పీకర్, Mikhail Bizhan, నా ఆసక్తిని ఆకర్షించారు. తన ప్రసంగంలో, వారు క్రమంగా తమ బృందాలను DevOpsలో ఎలా కట్టిపడేస్తున్నారు, వారికి ఇది ఎందుకు అవసరం మరియు DevOps రూపాంతరం యొక్క ఆలోచనను వ్యాపారానికి ఎలా విక్రయించాలి అనే దాని గురించి మాట్లాడారు. బాగా, సాధారణంగా, నేను పైప్లైన్ చివరిలో కాంతిని ఎలా చూడాలో గురించి మాట్లాడాను.
మిఖాయిల్ బిజాన్, రైఫీసెన్‌బ్యాంక్‌లో ఆటోమేషన్ డైరెక్టర్
ఇప్పుడు వారి కంపెనీలో "DevOps" లేదు. అంటే, అతను పని చేస్తాడు, కానీ అన్ని జట్లలో కాదు. DevOpsని అమలు చేస్తున్నప్పుడు, వారు నిర్దిష్ట ఇంజనీర్ల పరంగా మరియు ఉత్పత్తి యొక్క అవసరం మరియు ఈ ఉత్పత్తి నిర్మించబడిన ప్లాట్‌ఫారమ్ యొక్క పరిపక్వత పరంగా రెండు బృందాల సంసిద్ధతపై ఆధారపడతారు. DevOps ఎందుకు అవసరమో వ్యాపారానికి ఎలా వివరించాలో మిషా చెప్పారు.
బ్యాంకింగ్ విభాగంలో అనేక వృద్ధి డ్రైవర్లు ఉన్నాయి: సేవల ఖర్చు మరియు క్లయింట్ బేస్ విస్తరణ. సేవల ధరను పెంచడం చాలా మంచి డ్రైవర్ కాదు, కానీ క్లయింట్ బేస్ పెరగడం దీనికి విరుద్ధంగా ఉంటుంది. పోటీదారులు నిష్పక్షపాతంగా చల్లని ఉత్పత్తిని విడుదల చేస్తే, కస్టమర్లందరూ అక్కడికి వెళతారు, కాలక్రమేణా మార్కెట్ స్థాయిలు తగ్గుతాయి. అందువల్ల, మార్కెట్‌కు కొత్త ఉత్పత్తులను పరిచయం చేయడం మరియు వాటి పరిచయం యొక్క వేగం బ్యాంకులు దృష్టి సారించే ప్రధాన విషయం. DevOps ఖచ్చితంగా దీని కోసమే, మరియు వ్యాపారాలు దీనిని అర్థం చేసుకుంటాయి.
తదుపరి ముఖ్యమైన గమనిక: DevOps ఎల్లప్పుడూ మార్కెట్‌కి సమయాన్ని తగ్గించదు. DevOps ఒంటరిగా పని చేయదు, ఇది అభివృద్ధి నుండి ఉత్పత్తికి (కోడ్ నుండి కస్టమర్ వరకు) ఉత్పత్తిని సృష్టించడం మరియు మార్కెట్‌కు తీసుకువచ్చే ప్రక్రియలో భాగం. కానీ కోడ్‌కు ముందు ఉన్న ప్రతిదీ నేరుగా DevOpsకి సంబంధించినది కాదు. అంటే, విక్రయదారులు మార్కెట్‌ను సంవత్సరాల తరబడి అధ్యయనం చేయవచ్చు మరియు పోటీదారులతో కలిసి తమ జీవితమంతా గడపవచ్చు. క్లయింట్‌కు ఏమి అవసరమో త్వరగా అర్థం చేసుకోవడం మరియు ఈ లేదా ఆ ఫీచర్ యొక్క అమలును ప్లాన్ చేయడం అవసరం - తరచుగా ఇది DevOps పని చేయడానికి మరియు సంస్థ తన లక్ష్యాన్ని సాధించడానికి సరిపోదు. అందువల్ల, అన్నింటిలో మొదటిది, DevOps ఎలా ఉపయోగించాలో నేర్చుకోవడం అవసరమని Raiffeisenbank వ్యాపారంతో అంగీకరించింది. ఆటోమేషన్ కోసం ఆటోమేషన్ కొత్త కస్టమర్ల కోసం పోరాటంలో పెద్దగా సహాయం చేయదు.
సాధారణంగా, DevOpsని అమలు చేయాల్సిన అవసరం ఉందని మిషా అభిప్రాయపడ్డారు, కానీ తెలివిగా. మరియు పరివర్తన ప్రారంభంలో జట్టు యొక్క ఉత్పాదకత పడిపోతుంది, అది తక్కువ డబ్బు సంపాదిస్తుంది, కానీ అది సమర్థించబడుతుందనే వాస్తవం కోసం మనం సిద్ధంగా ఉండాలి.
మ్యాంగో టెలికాం వద్ద ఆటోమేషన్ ఆఫ్ టెస్టింగ్
టెస్టర్‌గా నాకు మరో ఆసక్తికరమైన నివేదికను మ్యాంగో టెలికాం నుండి ఎగోర్ మస్లోవ్ అందించారు. ప్రదర్శన "SCRUM బృందంలో పూర్తి పరీక్ష చక్రం యొక్క ఆటోమేషన్" అని పిలువబడింది. DevOps ప్రత్యేకంగా SCRUM కోసం సృష్టించబడిందని Egor అభిప్రాయపడ్డారు, అయితే అదే సమయంలో, DevOpsని SCRUM బృందంలో ప్రవేశపెట్టడం చాలా సమస్యాత్మకమైనది. SCRUM బృందం ఎల్లప్పుడూ ఎక్కడో ఒకచోట రన్ అవుతున్నందున ఇది జరుగుతుంది, ఆవిష్కరణల ద్వారా దృష్టి మరల్చడానికి మరియు ప్రక్రియను పునర్నిర్మించడానికి సమయం ఉండదు. SCRUM జట్టులోని ఉప-జట్ల విభజనను కలిగి ఉండదు (పరీక్ష బృందం, అభివృద్ధి బృందం మరియు మొదలైనవి) సమస్య కూడా ఉంది. అలాగే, ఇప్పటికే ఉన్న ప్రక్రియను ఆటోమేట్ చేయడానికి, డాక్యుమెంటేషన్ అవసరం, మరియు SCRUM లో, చాలా తరచుగా డాక్యుమెంటేషన్ పూర్తిగా ఉండదు - "ఒక రకమైన రచన కంటే ఉత్పత్తి చాలా ముఖ్యమైనది."
SCRUMకి మారిన తర్వాత, టెస్టర్లు ఫీచర్లను ఎలా పరీక్షించాలనే దానిపై డెవలపర్‌లతో సంప్రదించడం ప్రారంభించారు. క్రమంగా, ఫంక్షనాలిటీ పరిమాణం పెరిగింది, డాక్యుమెంటేషన్ లేదు, మరియు వారు పరీక్షల ద్వారా కవర్ చేయని ఫంక్షనాలిటీలో చాలా బగ్‌లను పట్టుకోవడం ప్రారంభించారు మరియు సాధారణంగా ఎవరు మరియు ఎప్పుడు పరీక్షించారో స్పష్టంగా తెలియదు. క్లుప్తంగా - గందరగోళం మరియు ఊగిసలాట. మేము టెస్టింగ్ ఆటోమేషన్‌కు మారాలని నిర్ణయించుకున్నాము. అయితే అప్పుడు కూడా పూర్తిగా విఫలమైంది. వారు అంతర్గత పరీక్షకులకు తెలియని స్టాక్‌పై వ్రాసిన అవుట్‌సోర్స్ ఆటోమేషన్ నిపుణులను నియమించుకున్నారు. ఆటోటెస్ట్‌ల కోసం ఫ్రేమ్‌వర్క్ పని చేసింది, అయితే అవుట్‌సోర్సర్‌లు నిష్క్రమించిన తర్వాత, ఇది రెండు వారాల పాటు కొనసాగింది. తదుపరిది ఆటోటెస్టింగ్ నంబర్ టూని పరిచయం చేసే ప్రయత్నం. SCRUM యొక్క ఫ్రేమ్‌వర్క్‌లో మీ స్వంతంగా (సరైన వెక్టర్: అంతర్గతంగా నైపుణ్యాన్ని పెంచుకోవడం), మరియు ప్రక్రియలో డాక్యుమెంటేషన్‌ను రూపొందించడం ద్వారా ప్రతిదీ కంపెనీలో నిర్మించబడాలి అనే వాస్తవంతో ఇది ప్రారంభమైంది. ఆటోమేషన్ కోసం స్టాక్ ఉత్పత్తి యొక్క స్టాక్‌కు సమానంగా ఉండాలి (ఇక్కడ నేను జోడిస్తున్నాను, మీ జావాస్క్రిప్ట్ ప్రాజెక్ట్‌ను వేరే దేనితోనూ పరీక్షించవద్దు). స్ప్రింట్ ముగింపులో, వారు మొత్తం బృందంతో (సహాయకరమైనది) ఆటోటెస్ట్ ఎలా పని చేస్తుందో డెమో చేసారు. అందువలన, ఆటోమేషన్ ప్రక్రియలో జట్టు సభ్యులందరి ప్రమేయం పెరిగింది, అలాగే ఆటోటెస్ట్‌లపై నమ్మకం మరియు ఈ ఆటోటెస్ట్ ఖచ్చితంగా ఉపయోగించబడే అవకాశం (మరియు స్థిరమైన వైఫల్యాల కారణంగా ఒక నెలలో వ్యాఖ్యానించబడదు).
మార్గం ద్వారా, DevOpsForum 2019లో ఓపెన్ మైక్రోఫోన్ ఉంది - ఇది చాలా కాలంగా తెలిసిన మరియు నా అభిప్రాయం ప్రకారం, ప్రసంగాల యొక్క ఉపయోగకరమైన ఆకృతి. మీరు ఇలా తిరుగుతారు, నివేదికలను వినండి, ఆపై సమావేశంలో ఒక నిర్దిష్ట అంశం లేదా సమస్యను చర్చించడం, సమస్యను పరిష్కరించడంలో సంబంధిత అనుభవాన్ని పంచుకోవడం విలువైనదని నిర్ణయించుకోండి.
నిర్వాహకులు చిన్న నివేదికల స్ట్రీమ్‌ను తయారు చేయడం కూడా నేను గమనించాను. ప్రతి నివేదిక 10 నిమిషాల కంటే ఎక్కువ సమయం ఉండదు, తర్వాత ప్రశ్నలు ఉంటాయి. ఈ విధంగా మీరు ఒకేసారి అనేక అంశాలను కవర్ చేయవచ్చు మరియు మీకు ఆసక్తి ఉన్న స్పీకర్లను ప్రశ్నలు అడగవచ్చు.
ప్రెజెంటేషన్‌ల మధ్య, నేను కాన్ఫరెన్స్ భాగస్వాముల బూత్‌ల చుట్టూ తిరిగాను మరియు చాలా వస్తువులను దొంగిలించాను/గెలుచుకున్నాను. ఓహ్, నేను కరపత్రాన్ని ప్రేమిస్తున్నాను!
Alfastrakhovanieలో డెవలప్‌మెంట్ డైరెక్టర్‌తో రౌండ్ టేబుల్ మరియు DevOps సమస్యలు
నా కోసం DevOpsForum 2019 కేక్‌పై ఐసింగ్ DevOps నిపుణులతో గంటసేపు జరిగిన ప్లీనరీ సెషన్. వివిధ కోణాల నుండి DevOpsని చూడటానికి నలుగురు సెషన్ పాల్గొనేవారు ఆహ్వానించబడ్డారు: అంటోన్ ఇసానిన్ (అల్ఫాస్ట్రాఖోవానీ, డెవలప్‌మెంట్ డైరెక్టర్), నైల్యా జమాష్కినా (ఫిన్‌టెక్ ల్యాబ్, ఆపరేటింగ్ డైరెక్టర్), ఒలేగ్ ఎగోర్కిన్ (రోస్టెలెకామ్, ఎజైల్ కోచ్) మరియు అంటోన్ మార్టియనోవ్ (స్వతంత్ర నిపుణుడు, DevOps వైపు చూశారు. వ్యాపార దృక్కోణం నుండి).
నిపుణులు ప్రజలకు దగ్గరగా కూర్చున్నారు మరియు తరువాత విషయాలు జరగడం ప్రారంభించాయి: మొత్తం గంట పాటు, ప్రేక్షకుల నుండి పాల్గొనేవారు వారి ప్రశ్నలను అడిగారు మరియు నిపుణులు ర్యాప్ తీసుకున్నారు. కొన్నిసార్లు నిజమైన చర్చలు జరిగాయి. ప్రశ్నలు చాలా భిన్నంగా ఉన్నాయి, ఉదాహరణకు: DevOps ఇంజనీర్లు అవసరమా, వారు సిస్టమ్ అడ్మినిస్ట్రేటర్‌లుగా ఎందుకు శిక్షణ పొందలేరు, ప్రతి ఒక్కరికీ DevOps అందించబడాలి, దాని విలువ ఏమిటి మరియు మొదలైనవి.
అప్పుడు, నేను అంటోన్ ఇసానిన్‌తో వ్యక్తిగతంగా మాట్లాడాను. మేము ప్రతి ఇంటికి DevOps సంస్కృతిని తీసుకురావాల్సిన అవసరాన్ని చర్చించాము మరియు DevOps పరివర్తన యొక్క చీకటి కోణాన్ని వెల్లడించాము.
ప్రతి ఒక్కరూ ఒకచోట చేరి, ఉత్పత్తి మరియు వ్యాపారం మరియు బృందం రెండింటికీ DevOps అవసరమని నిర్ణయించుకున్నారని ఊహించండి. దాన్ని అమలు చేద్దాం. అంతా వర్క్ అవుట్ అయింది. మేము ఊపిరి పీల్చుకున్నాము. DevOps మమ్మల్ని క్లయింట్‌కి దగ్గర చేసింది, ఇప్పుడు మేము అతని కోరికలన్నింటినీ త్వరగా తీర్చగలము. ఫలితంగా, మేము కఠినమైన నిబంధనలు మరియు అవసరాలతో పెద్ద Ops విభాగాన్ని కలిగి ఉన్నాము మరియు ఇది నిరంతరం ఉత్పత్తిలో లోపాలను కనుగొంటుంది మరియు అభ్యర్థనల సమూహాన్ని సృష్టిస్తుంది. అంతేకాకుండా, క్లయింట్ ఊహించని విధంగా బటన్‌ను ఆకుపచ్చ రంగుకు బదులుగా పసుపు రంగులో వేయాలనుకున్నప్పటికీ, అన్ని లోపాలు "అత్యవసర" స్థితిని కేటాయించబడతాయి. ప్రాజెక్ట్ పెరుగుతోంది, విడుదలల సంఖ్య పెరుగుతోంది మరియు తదనుగుణంగా, క్లయింట్లచే కొత్త కార్యాచరణ యొక్క లోపాలు మరియు అపార్థాల సంఖ్య. లోపాలను నివేదించడానికి Ops మరో 10 మంది వ్యక్తులను తీసుకుంటుంది మరియు వాటిని మూసివేయడానికి డెవలప్‌మెంట్ మరో 15 మందిని తీసుకుంటుంది. మరియు కొత్త ఫీచర్లను పరిచయం చేయడానికి బదులుగా, బృందం అంతులేని SDలతో పని చేస్తుంది, వినియోగదారుకు కార్యాచరణను వివరిస్తుంది మరియు అదే సమయంలో మద్దతు ఇస్తుంది. ఫలితంగా, Ops మరియు అభివృద్ధి రెండూ వ్యాపారంలో ఉన్నాయి, కానీ క్లయింట్ మరియు వ్యాపారం అసంతృప్తిగా ఉన్నాయి: కొత్త ఫీచర్లు నిలిచిపోయాయి. DevOps ఉనికిలో ఉన్నట్లు కనిపిస్తోంది, కానీ అది ఉనికిలో లేదు.
DevOpsను అమలు చేయవలసిన అవసరానికి సంబంధించి, ఇది నేరుగా వ్యాపార స్థాయిపై ఆధారపడి ఉంటుందని అంటోన్ స్పష్టంగా పేర్కొన్నాడు. సంవత్సరానికి ఒక క్లయింట్‌కు సేవ చేయడం ద్వారా కంపెనీకి బిలియన్‌లు అందజేస్తే, DevOps అవసరం లేదు (మీరు ఈ క్లయింట్‌కి క్రమం తప్పకుండా కొత్త మార్పులను అందించాల్సిన అవసరం లేదు). అంతా చాక్లెట్‌తో కప్పబడి ఉంది. కానీ వ్యాపారం పెరిగి, ఎక్కువ మంది క్లయింట్లు కనిపిస్తే, మీరు కట్టుబడి ఉండాలి. నియమం ప్రకారం, ప్రారంభంలో కంపెనీలో కూల్ ఆప్స్ లేదు. మొదట మేము ఉత్పత్తిని కత్తిరించాము మరియు ఉత్పత్తి పని చేయడానికి, మేము సర్వర్‌లపై ఒక కన్ను వేసి, సరఫరాలను పర్యవేక్షించాల్సిన అవసరం ఉందని మేము అర్థం చేసుకున్నాము. అప్పుడే ఆప్స్ ఉనికిలోకి వస్తుంది. Ops, ఒక ప్రత్యేక విభాగంగా, అభివృద్ధికి అడ్డంకుల సమూహాన్ని ఉంచడం ప్రారంభిస్తుందని మరియు అన్ని డెలివరీలు నిలిచిపోవడం ప్రారంభమవుతుందని అర్థం చేసుకోవాలి. అంటే, ఈ సందర్భంలో, DevOps సంస్కృతి ఇప్పటికే సంబంధితంగా ఉంది, కానీ దాని చీకటి వైపు గురించి మనం మరచిపోకూడదు.
మూలం: www.habr.com