మీరు ITలో పని చేస్తున్నప్పుడు, సిస్టమ్‌లు వాటి స్వంత పాత్రను కలిగి ఉన్నాయని మీరు గమనించడం ప్రారంభిస్తారు. అవి అనువైనవి, నిశ్శబ్దం, అసాధారణమైనవి మరియు దృఢమైనవి. వారు ఆకర్షించగలరు లేదా తిప్పికొట్టగలరు. ఒక మార్గం లేదా మరొకటి, మీరు వారితో "చర్చలు" చేయాలి, "ఆపదల" మధ్య యుక్తిని మరియు వారి పరస్పర చర్య యొక్క గొలుసులను నిర్మించాలి.
కాబట్టి మేము క్లౌడ్ ప్లాట్‌ఫారమ్‌ను నిర్మించే గౌరవాన్ని పొందాము మరియు దీని కోసం మేము మాతో కలిసి పని చేయడానికి కొన్ని ఉపవ్యవస్థలను "ఒప్పించడం" అవసరం. అదృష్టవశాత్తూ, మాకు “API భాష”, ప్రత్యక్ష చేతులు మరియు చాలా ఉత్సాహం ఉన్నాయి.
ఈ కథనం సాంకేతికంగా హార్డ్‌కోర్ కాదు, కానీ క్లౌడ్‌ను నిర్మించేటప్పుడు మేము ఎదుర్కొన్న సమస్యలను వివరిస్తుంది. మేము సిస్టమ్‌లతో ఒక సాధారణ భాష కోసం ఎలా వెతుకుతున్నామో మరియు దాని నుండి ఏమి వచ్చింది అనే దాని గురించి తేలికపాటి సాంకేతిక ఫాంటసీ రూపంలో మా మార్గాన్ని వివరించాలని నేను నిర్ణయించుకున్నాను.
పిల్లికి స్వాగతం.
మార్గం ప్రారంభం
కొంతకాలం క్రితం, మా క్లయింట్‌ల కోసం క్లౌడ్ ప్లాట్‌ఫారమ్‌ను ప్రారంభించడం మా బృందం పని. సేవ యొక్క సాఫ్ట్‌వేర్ భాగాన్ని అమలు చేయడానికి సాంకేతికతలను ఎంచుకోవడంలో మాకు నిర్వహణ మద్దతు, వనరులు, హార్డ్‌వేర్ స్టాక్ మరియు స్వేచ్ఛ ఉన్నాయి.
అనేక అవసరాలు కూడా ఉన్నాయి:
- సేవకు అనుకూలమైన వ్యక్తిగత ఖాతా అవసరం;
- ప్లాట్‌ఫారమ్ తప్పనిసరిగా ఇప్పటికే ఉన్న బిల్లింగ్ సిస్టమ్‌లో విలీనం చేయబడాలి;
- సాఫ్ట్‌వేర్ మరియు హార్డ్‌వేర్: OpenStack + Tungsten Fabric (Open Contrail), మా ఇంజనీర్లు బాగా “వండడం” నేర్చుకున్నారు.
హబ్రా కమ్యూనిటీకి ఆసక్తి ఉంటే, బృందం ఎలా సమావేశమైంది, వ్యక్తిగత ఖాతా ఇంటర్‌ఫేస్ అభివృద్ధి చేయబడింది మరియు డిజైన్ నిర్ణయాలు తీసుకోవడం గురించి మేము మీకు మరొకసారి చెబుతాము.
మేము ఉపయోగించాలని నిర్ణయించుకున్న సాధనాలు:
- పైథాన్ + ఫ్లాస్క్ + స్వాగర్ + SQLAlchemy - పూర్తిగా ప్రామాణికమైన పైథాన్ సెట్;
- ఫ్రంటెండ్ కోసం Vue.js;
- మేము AMQP ద్వారా Celeryని ఉపయోగించి భాగాలు మరియు సేవల మధ్య పరస్పర చర్య చేయాలని నిర్ణయించుకున్నాము.
పైథాన్‌ని ఎంచుకోవడం గురించి ఎదురు ప్రశ్నలు, నేను వివరిస్తాను. భాష మా కంపెనీలో దాని సముచిత స్థానాన్ని కనుగొంది మరియు దాని చుట్టూ ఒక చిన్న, కానీ ఇప్పటికీ సంస్కృతి అభివృద్ధి చెందింది. అందువల్ల, దానిపై సేవను నిర్మించడం ప్రారంభించాలని నిర్ణయించారు. అంతేకాకుండా, అటువంటి సమస్యలలో అభివృద్ధి వేగం తరచుగా నిర్ణయాత్మకంగా ఉంటుంది.
కాబట్టి, మన పరిచయాన్ని ప్రారంభిద్దాం.
నిశ్శబ్ద బిల్లు - బిల్లింగ్
ఈ వ్యక్తి మాకు చాలా కాలంగా తెలుసు. ఎప్పుడూ నా పక్కనే కూర్చుని మౌనంగా ఏదో లెక్కపెట్టేవాడు. కొన్నిసార్లు అతను వినియోగదారు అభ్యర్థనలను మాకు ఫార్వార్డ్ చేశాడు, క్లయింట్ ఇన్‌వాయిస్‌లను జారీ చేశాడు మరియు సేవలను నిర్వహించాడు. కష్టపడి పనిచేసే సాధారణ వ్యక్తి. నిజమే, ఇబ్బందులు ఉన్నాయి. అతను నిశ్శబ్దంగా ఉంటాడు, కొన్నిసార్లు ఆలోచనాత్మకంగా ఉంటాడు మరియు తరచుగా తన స్వంత మనస్సులో ఉంటాడు.
మేము స్నేహం చేయడానికి ప్రయత్నించిన మొదటి సిస్టమ్ బిల్లింగ్. మరియు సేవలను ప్రాసెస్ చేస్తున్నప్పుడు మేము ఎదుర్కొన్న మొదటి కష్టం.
ఉదాహరణకు, సృష్టించినప్పుడు లేదా తొలగించబడినప్పుడు, ఒక పని అంతర్గత బిల్లింగ్ క్యూలోకి వెళుతుంది. అందువలన, సేవలతో అసమకాలిక పని వ్యవస్థ అమలు చేయబడుతుంది. మా సేవా రకాలను ప్రాసెస్ చేయడానికి, మేము మా పనులను ఈ క్యూలో “పుట్” చేయాలి. మరియు ఇక్కడ మేము ఒక సమస్యలో పడ్డాము: డాక్యుమెంటేషన్ లేకపోవడం.
సాఫ్ట్‌వేర్ API యొక్క వివరణను బట్టి చూస్తే, ఈ సమస్యను పరిష్కరించడం ఇప్పటికీ సాధ్యమే, కానీ రివర్స్ ఇంజనీరింగ్ చేయడానికి మాకు సమయం లేదు, కాబట్టి మేము లాజిక్‌ను బయటికి తీసుకుని, RabbitMQ పైన టాస్క్ క్యూను నిర్వహించాము. సేవపై ఒక ఆపరేషన్ క్లయింట్ తన వ్యక్తిగత ఖాతా నుండి ప్రారంభించబడుతుంది, బ్యాకెండ్‌లో సెలెరీ "టాస్క్"గా మారుతుంది మరియు బిల్లింగ్ మరియు ఓపెన్స్టాక్ వైపు నిర్వహించబడుతుంది. సెలెరీ పనులను నిర్వహించడానికి, పునరావృతాలను నిర్వహించడానికి మరియు స్థితిని పర్యవేక్షించడానికి చాలా సౌకర్యవంతంగా ఉంటుంది. మీరు "సెలెరీ" గురించి మరింత చదువుకోవచ్చు, ఉదాహరణకు, .
అలాగే, డబ్బు లేని ప్రాజెక్ట్‌ను బిల్లింగ్ ఆపలేదు. డెవలపర్‌లతో కమ్యూనికేట్ చేస్తూ, గణాంకాలను లెక్కించేటప్పుడు (మరియు మేము ఖచ్చితంగా ఈ రకమైన లాజిక్‌ను అమలు చేయాలి), ఆపే నియమాలకు సంక్లిష్టమైన పరస్పర సంబంధం ఉందని మేము కనుగొన్నాము. కానీ ఈ నమూనాలు మన వాస్తవాలకు సరిగ్గా సరిపోవు. మేము సర్వీస్ మేనేజ్‌మెంట్ లాజిక్‌ను బ్యాకెండ్ వైపుకు తీసుకొని, సెలెరీలో టాస్క్‌ల ద్వారా కూడా దీన్ని అమలు చేసాము.
పైన పేర్కొన్న రెండు సమస్యలు కోడ్ కొద్దిగా ఉబ్బినట్లు మారడానికి దారితీశాయి మరియు భవిష్యత్తులో టాస్క్‌లతో పని చేయడానికి లాజిక్‌ను ప్రత్యేక సేవలోకి తరలించడానికి మేము రీఫ్యాక్టర్ చేయాల్సి ఉంటుంది. ఈ లాజిక్‌కు మద్దతు ఇవ్వడానికి మేము మా పట్టికలలో వినియోగదారులు మరియు వారి సేవల గురించి కొంత సమాచారాన్ని కూడా నిల్వ చేయాలి.
మరో సమస్య నిశ్శబ్దం.
బిల్లీ కొన్ని API అభ్యర్థనలకు నిశ్శబ్దంగా "సరే" అని సమాధానం ఇస్తాడు. ఉదాహరణకు, మేము పరీక్ష సమయంలో వాగ్దానం చేసిన చెల్లింపుల చెల్లింపులు చేసినప్పుడు ఇది జరిగింది (తర్వాత మరింత). అభ్యర్థనలు సరిగ్గా అమలు చేయబడ్డాయి మరియు మాకు ఎటువంటి లోపాలు కనిపించలేదు.
UI ద్వారా సిస్టమ్‌తో పని చేస్తున్నప్పుడు నేను లాగ్‌లను అధ్యయనం చేయాల్సి వచ్చింది. బిల్లింగ్ కూడా ఇలాంటి అభ్యర్థనలను చేస్తుందని తేలింది, స్కోప్‌ను నిర్దిష్ట వినియోగదారుకు మారుస్తుంది, ఉదాహరణకు, అడ్మిన్, దానిని su పారామీటర్‌లో పాస్ చేయడం.
సాధారణంగా, డాక్యుమెంటేషన్‌లో ఖాళీలు మరియు చిన్న API లోపాలు ఉన్నప్పటికీ, ప్రతిదీ చాలా బాగా జరిగింది. లాగ్‌లు ఎలా నిర్మాణాత్మకంగా ఉన్నాయో మరియు దేని కోసం వెతకాలో మీరు అర్థం చేసుకుంటే అధిక భారంలో కూడా చదవవచ్చు. డేటాబేస్ యొక్క నిర్మాణం అలంకరించబడినది, కానీ చాలా లాజికల్ మరియు కొన్ని మార్గాల్లో కూడా ఆకర్షణీయంగా ఉంటుంది.
కాబట్టి, సంగ్రహంగా చెప్పాలంటే, పరస్పర చర్య దశలో మేము ఎదుర్కొన్న ప్రధాన సమస్యలు నిర్దిష్ట సిస్టమ్ యొక్క అమలు లక్షణాలకు సంబంధించినవి:
- ఒక విధంగా లేదా మరొక విధంగా మమ్మల్ని ప్రభావితం చేసే నమోదుకాని "లక్షణాలు";
- క్లోజ్డ్ సోర్స్ (బిల్లింగ్ C++లో వ్రాయబడింది), ఫలితంగా - "ట్రయల్ అండ్ ఎర్రర్" కాకుండా ఏ విధంగానైనా సమస్య 1ని పరిష్కరించడం అసాధ్యం.
అదృష్టవశాత్తూ, ఉత్పత్తి చాలా విస్తృతమైన APIని కలిగి ఉంది మరియు మేము మా వ్యక్తిగత ఖాతాలో క్రింది ఉపవ్యవస్థలను ఏకీకృతం చేసాము:
- సాంకేతిక మద్దతు మాడ్యూల్ - సేవా క్లయింట్‌ల కోసం పారదర్శకంగా బిల్లింగ్ చేయడానికి మీ వ్యక్తిగత ఖాతా నుండి అభ్యర్థనలు “ప్రాక్సీడ్”;
- ఆర్థిక మాడ్యూల్ - ప్రస్తుత క్లయింట్‌లకు ఇన్‌వాయిస్‌లను జారీ చేయడానికి, రైట్-ఆఫ్‌లు చేయడానికి మరియు చెల్లింపు పత్రాలను రూపొందించడానికి మిమ్మల్ని అనుమతిస్తుంది;
- సేవా నియంత్రణ మాడ్యూల్ - దీని కోసం మేము మా స్వంత హ్యాండ్లర్‌ను అమలు చేయాల్సి వచ్చింది. సిస్టమ్ యొక్క విస్తరణ మా చేతుల్లోకి వచ్చింది మరియు మేము బిల్లీకి కొత్త రకమైన సేవను "బోధించాము".
ఇది కొంచెం ఇబ్బందిగా ఉంది, కానీ ఒక మార్గం లేదా మరొకటి, నేను మరియు బిల్లీతో కలిసిపోతామని నేను అనుకుంటున్నాను.
టంగ్స్టన్ క్షేత్రాల గుండా నడవడం - టంగ్స్టన్ ఫ్యాబ్రిక్
టంగ్స్టన్ ఫీల్డ్‌లు వందలాది వైర్‌లతో నిండి ఉన్నాయి, వాటి ద్వారా వేల బిట్‌ల సమాచారాన్ని పంపుతున్నాయి. సమాచారం "ప్యాకెట్లు" లోకి సేకరించబడుతుంది, అన్వయించబడింది, మాయాజాలం వలె సంక్లిష్ట మార్గాలను నిర్మించడం.
ఇది మేము స్నేహితులను చేసుకోవలసిన రెండవ సిస్టమ్ యొక్క డొమైన్ - టంగ్స్టన్ ఫ్యాబ్రిక్ (TF), గతంలో OpenContrail. నెట్వర్క్ పరికరాలను నిర్వహించడం దీని పని, వినియోగదారులుగా మాకు సాఫ్ట్‌వేర్ సంగ్రహాన్ని అందించడం. TF - SDN, నెట్వర్క్ పరికరాలతో పని చేసే సంక్లిష్ట తర్కాన్ని కలుపుతుంది. సాంకేతికత గురించి మంచి కథనం ఉంది, ఉదాహరణకు, .
సిస్టమ్ న్యూట్రాన్ ప్లగ్ఇన్ ద్వారా ఓపెన్స్టాక్ (క్రింద చర్చించబడింది)తో ఏకీకృతం చేయబడింది.
OpenStack సేవల పరస్పర చర్య.
ఆపరేషన్స్ విభాగానికి చెందిన కుర్రాళ్లు మాకు ఈ వ్యవస్థను పరిచయం చేశారు. మా సేవల నెట్వర్క్ స్టాక్‌ను నిర్వహించడానికి మేము సిస్టమ్ APIని ఉపయోగిస్తాము. ఇది మాకు ఇంకా ఎటువంటి తీవ్రమైన సమస్యలు లేదా అసౌకర్యాలను కలిగించలేదు (OE నుండి వచ్చిన అబ్బాయిల కోసం నేను మాట్లాడలేను), కానీ పరస్పర చర్యలో కొన్ని విచిత్రాలు ఉన్నాయి.
మొదటిది ఇలా కనిపించింది: SSH ద్వారా కనెక్ట్ చేస్తున్నప్పుడు ఇన్‌స్టాన్స్ కన్సోల్‌కు పెద్ద మొత్తంలో డేటాను అవుట్‌పుట్ చేయాల్సిన కమాండ్‌లు కనెక్షన్‌ను “హ్యాంగ్ అప్” చేస్తాయి, అయితే VNC ద్వారా ప్రతిదీ సరిగ్గా పని చేస్తుంది.
సమస్య గురించి తెలియని వారికి, ఇది చాలా ఫన్నీగా కనిపిస్తుంది: ls / రూట్ సరిగ్గా పనిచేస్తుంది, ఉదాహరణకు, టాప్ పూర్తిగా "ఫ్రీజ్" అవుతుంది. అదృష్టవశాత్తూ, మేము ఇంతకు ముందు ఇలాంటి సమస్యలను ఎదుర్కొన్నాము. కంప్యూట్ నోడ్‌ల నుండి రూటర్‌లకు మార్గంలో MTUని ట్యూన్ చేయడం ద్వారా ఇది నిర్ణయించబడింది. మార్గం ద్వారా, ఇది TF సమస్య కాదు.
తదుపరి సమస్య కేవలం మూలలో ఉంది. ఒక "అందమైన" క్షణంలో, రౌటింగ్ యొక్క మాయాజాలం అదృశ్యమైంది. TF పరికరాలలో రూటింగ్ నిర్వహణను నిలిపివేసింది.
మేము నిర్వాహక స్థాయి నుండి Openstackతో పని చేసాము మరియు ఆ తర్వాత అవసరమైన వినియోగదారు స్థాయికి మారాము. SDN చర్యలు నిర్వహించబడే వినియోగదారు యొక్క పరిధిని "హైజాక్" చేసినట్లుగా కనిపిస్తుంది. వాస్తవం ఏమిటంటే TF మరియు OpenStackలను కనెక్ట్ చేయడానికి అదే నిర్వాహక ఖాతా ఉపయోగించబడుతుంది. వినియోగదారుకు మారే దశలో, "మేజిక్" అదృశ్యమైంది. సిస్టమ్‌తో పనిచేయడానికి ప్రత్యేక ఖాతాను సృష్టించాలని నిర్ణయించారు. ఇది ఇంటిగ్రేషన్ ఫంక్షనాలిటీని విచ్ఛిన్నం చేయకుండా పని చేయడానికి మాకు అనుమతి ఇచ్చింది.
సిలికాన్ లైఫ్‌ఫారమ్‌లు - ఓపెన్స్టాక్
ఒక వికారమైన ఆకారంలో ఉన్న సిలికాన్ జీవి టంగ్స్టన్ క్షేత్రాల సమీపంలో నివసిస్తుంది. అన్నిటికంటే మించి ఒక్క ఊపుతో మనల్ని చితకబాదిన పిల్లవాడిలా కనిపిస్తున్నా అతని నుంచి స్పష్టమైన దూకుడు కనిపించడం లేదు. ఇది భయాన్ని కలిగించదు, కానీ దాని పరిమాణం భయాన్ని ప్రేరేపిస్తుంది. చుట్టూ ఏమి జరుగుతుందో సంక్లిష్టత వలె.
OpenStack మా ప్లాట్‌ఫారమ్ యొక్క ప్రధాన అంశం.
OpenStack అనేక ఉపవ్యవస్థలను కలిగి ఉంది, వాటిలో మేము ప్రస్తుతం Nova, Glance మరియు Cinderలను అత్యంత చురుకుగా ఉపయోగిస్తున్నాము. వాటిలో ప్రతి దాని స్వంత API ఉంది. గణన వనరులు మరియు ఉదాహరణల సృష్టికి నోవా బాధ్యత వహిస్తుంది, వాల్యూమ్‌లు మరియు వాటి స్నాప్‌షాట్‌లను నిర్వహించడానికి Cinder బాధ్యత వహిస్తుంది, గ్లాన్స్ అనేది OS టెంప్లేట్‌లను మరియు వాటిపై మెటైన్‌ఫర్మేషన్‌ను నిర్వహించే ఇమేజ్ సర్వీస్.
ప్రతి సేవ ఒక కంటైనర్‌లో నడుస్తుంది మరియు సందేశ బ్రోకర్ “తెల్ల కుందేలు” - RabbitMQ.
ఈ వ్యవస్థ మాకు ఊహించని ఇబ్బందిని ఇచ్చింది.
మరియు మేము అదనపు వాల్యూమ్‌ను సర్వర్‌కు కనెక్ట్ చేయడానికి ప్రయత్నించినప్పుడు మొదటి సమస్య చాలా కాలం కాదు. Cinder API ఈ విధిని నిర్వహించడానికి సున్నితంగా నిరాకరించింది. మరింత ఖచ్చితంగా, మీరు OpenStackను విశ్వసిస్తే, కనెక్షన్ స్థాపించబడింది, కానీ వర్చువల్ సర్వర్ లోపల డిస్క్ పరికరం లేదు.
మేము పక్కదారి పట్టాలని నిర్ణయించుకున్నాము మరియు Nova API నుండి అదే చర్యను అభ్యర్థించాము. ఫలితంగా పరికరం సరిగ్గా కనెక్ట్ చేయబడుతుంది మరియు సర్వర్‌లో యాక్సెస్ చేయబడుతుంది. బ్లాక్-స్టోరేజ్ Cinderకి ప్రతిస్పందించనప్పుడు సమస్య ఏర్పడినట్లు కనిపిస్తుంది.
డిస్క్‌లతో పనిచేసేటప్పుడు మరొక కష్టం మాకు ఎదురుచూస్తోంది. సిస్టమ్ వాల్యూమ్ సర్వర్ నుండి డిస్‌కనెక్ట్ చేయబడదు.
మళ్ళీ, ఓపెన్స్టాక్ కనెక్షన్‌ను నాశనం చేసిందని మరియు ఇప్పుడు మీరు వాల్యూమ్‌తో విడిగా పని చేయవచ్చు అని "ప్రమాణం" చేస్తుంది. కానీ API నిర్దిష్టంగా డిస్క్‌లో కార్యకలాపాలను నిర్వహించాలనుకోలేదు.
ఇక్కడ మేము ప్రత్యేకంగా పోరాడకూడదని నిర్ణయించుకున్నాము, కానీ సేవ యొక్క తర్కం గురించి మా అభిప్రాయాన్ని మార్చుకోవాలని నిర్ణయించుకున్నాము. ఒక ఉదాహరణ ఉంటే, సిస్టమ్ వాల్యూమ్ కూడా ఉండాలి. అందువల్ల, వినియోగదారు "సర్వర్" ను తొలగించకుండా సిస్టమ్ "డిస్క్" ను ఇంకా తీసివేయలేరు లేదా నిలిపివేయలేరు.
OpenStack అనేది దాని స్వంత ఇంటరాక్షన్ లాజిక్ మరియు అలంకరించబడిన APIతో కూడిన సంక్లిష్టమైన సిస్టమ్స్. మేము చాలా వివరణాత్మక డాక్యుమెంటేషన్ మరియు, వాస్తవానికి, ట్రయల్ మరియు ఎర్రర్ (అది లేకుండా మనం ఎక్కడ ఉంటాము) ద్వారా సహాయం చేస్తాము.
టెస్ట్ రన్
గతేడాది డిసెంబర్‌లో టెస్ట్ లాంచ్ నిర్వహించాం. సాంకేతిక వైపు నుండి మరియు UX వైపు నుండి పోరాట మోడ్‌లో మా ప్రాజెక్ట్‌ను పరీక్షించడం ప్రధాన పని. ప్రేక్షకులను ఎంపిక చేసి ఆహ్వానించారు మరియు పరీక్ష మూసివేయబడింది. అయినప్పటికీ, మేము మా వెబ్‌సైట్‌లో పరీక్షకు ప్రాప్యతను అభ్యర్థించడానికి ఎంపికను కూడా వదిలివేసాము.
పరీక్ష కూడా దాని ఫన్నీ క్షణాలు లేకుండా లేదు, ఎందుకంటే మన సాహసాలు ఇప్పుడే ప్రారంభమవుతున్నాయి.
ముందుగా, మేము ప్రాజెక్ట్‌పై ఆసక్తిని కొంతవరకు తప్పుగా అంచనా వేసాము మరియు పరీక్ష సమయంలో త్వరగా కంప్యూట్ నోడ్‌లను జోడించాల్సి వచ్చింది. క్లస్టర్ కోసం ఒక సాధారణ సందర్భం, కానీ ఇక్కడ కూడా కొన్ని సూక్ష్మ నైపుణ్యాలు ఉన్నాయి. TF యొక్క నిర్దిష్ట సంస్కరణ కోసం డాక్యుమెంటేషన్ vRouterతో పని చేసే కెర్నల్ యొక్క నిర్దిష్ట సంస్కరణను సూచిస్తుంది. మేము ఇటీవలి కెర్నల్‌లతో నోడ్‌లను ప్రారంభించాలని నిర్ణయించుకున్నాము. ఫలితంగా, TF నోడ్స్ నుండి మార్గాలను అందుకోలేదు. నేను కెర్నల్‌లను అత్యవసరంగా వెనక్కి తిప్పవలసి వచ్చింది.
మరొక ఉత్సుకత మీ వ్యక్తిగత ఖాతాలోని "పాస్వర్డ్ మార్చు" బటన్ యొక్క కార్యాచరణకు సంబంధించినది.
సెషన్‌లతో పని చేయకుండా మా వ్యక్తిగత ఖాతాకు యాక్సెస్‌ని నిర్వహించడానికి మేము JWTని ఉపయోగించాలని నిర్ణయించుకున్నాము. సిస్టమ్‌లు విభిన్నమైనవి మరియు విస్తృతంగా చెల్లాచెదురుగా ఉన్నందున, మేము మా స్వంత టోకెన్‌ను నిర్వహిస్తాము, దీనిలో మేము బిల్లింగ్ నుండి సెషన్‌లను "వ్రాప్" చేస్తాము మరియు ఓపెన్స్టాక్ నుండి టోకెన్‌ను చేస్తాము. పాస్వర్డ్ మార్చబడినప్పుడు, టోకెన్, వాస్తవానికి, "చెడ్డది", ఎందుకంటే వినియోగదారు డేటా ఇకపై చెల్లదు మరియు దానిని మళ్లీ జారీ చేయాలి.
మేము ఈ పాయింట్‌ను కోల్పోయాము మరియు ఈ భాగాన్ని త్వరగా పూర్తి చేయడానికి తగినంత వనరులు లేవు. మేము పరీక్షను ప్రారంభించే ముందు కార్యాచరణను తగ్గించాల్సి వచ్చింది.
పాస్వర్డ్ మార్చబడితే ప్రస్తుతం మేము వినియోగదారుని లాగ్ అవుట్ చేస్తాము.
ఈ సూక్ష్మ నైపుణ్యాలు ఉన్నప్పటికీ, పరీక్ష బాగా జరిగింది. రెండు వారాల్లో దాదాపు 300 మంది ఆగిపోయారు. మేము ఉత్పత్తిని వినియోగదారుల దృష్టితో చూడగలిగాము, చర్యలో పరీక్షించగలిగాము మరియు అధిక-నాణ్యత అభిప్రాయాన్ని సేకరించగలిగాము.
కొనసాగించాలి
మనలో చాలా మందికి, ఇది ఈ స్థాయిలో మొదటి ప్రాజెక్ట్. మేము బృందంగా పని చేయడం మరియు నిర్మాణ మరియు డిజైన్ నిర్ణయాలు తీసుకోవడం గురించి అనేక విలువైన పాఠాలను నేర్చుకున్నాము. తక్కువ వనరులతో సంక్లిష్ట వ్యవస్థలను ఎలా సమగ్రపరచాలి మరియు వాటిని ఉత్పత్తిలోకి ఎలా మార్చాలి.
వాస్తవానికి, కోడ్ పరంగా మరియు సిస్టమ్ ఇంటిగ్రేషన్ యొక్క ఇంటర్‌ఫేస్‌లలో పని చేయడానికి ఏదైనా ఉంది. ప్రాజెక్ట్ చాలా చిన్నది, కానీ మేము దానిని నమ్మదగిన మరియు అనుకూలమైన సేవగా ఎదగాలనే ఆశయాలతో నిండి ఉన్నాము.
ఇప్పటికే వ్యవస్థలను ఒప్పించగలిగాం. బిల్ తన గదిలో లెక్కింపు, బిల్లింగ్ మరియు వినియోగదారు అభ్యర్థనలను విధిగా నిర్వహిస్తుంది. టంగ్స్టన్ ఫీల్డ్స్ యొక్క "మేజిక్" మాకు స్థిరమైన కమ్యూనికేషన్‌ను అందిస్తుంది. మరియు ఓపెన్స్టాక్ మాత్రమే కొన్నిసార్లు మోజుకనుగుణంగా ఉంటుంది, "'WSREP ఇంకా అప్లికేషన్ ఉపయోగం కోసం నోడ్‌ని సిద్ధం చేయలేదు" అని అరుస్తుంది. కానీ అది పూర్తిగా భిన్నమైన కథ…
మేము ఇటీవలే సేవను ప్రారంభించాము.
మీరు మాలో అన్ని వివరాలను తెలుసుకోవచ్చు .
CLO అభివృద్ధి బృందం
ఉపయోగకరమైన లింకులు
ఓపెన్స్టాక్
టంగ్స్టన్ ఫాబ్రిక్
మూలం: www.habr.com