12f-2 гэхэд
Дөрөвдүгээр сарын сүүлчээр Цагаан алхагчдыг Винтерфеллийг бүсэлж байх үед бидэнд илүү сонирхолтой зүйл тохиолдов; бид ер бусын эргэлт хийсэн. Зарчмын хувьд бид шинэ боломжуудыг үйлдвэрлэлд байнга нэвтрүүлж байдаг (бусдын нэгэн адил). Гэхдээ энэ нь өөр байсан. Үүний цар хүрээ нь бидний гаргаж болох аливаа алдаа нь манай бүх үйлчилгээ, хэрэглэгчдэд нөлөөлөх болно. Үүний үр дүнд бид бүх зүйлийг төлөвлөгөөний дагуу, төлөвлөсөн болон зарласан сул зогсолтын хугацаанд борлуулалтад ямар ч үр дагаваргүйгээр хүргэсэн. Энэ нийтлэлд бид үүнийг хэрхэн олж авсан, хэн ч үүнийг гэртээ хэрхэн давтаж болох талаар өгүүлнэ.
Би одоо бидний гаргасан архитектур, техникийн шийдвэрүүдийг тайлбарлахгүй, энэ бүхэн хэрхэн ажилладаг талаар ярихгүй. Эдгээр нь миний ажигласан, миний шууд оролцсон хамгийн хэцүү хувилбаруудын нэг хэрхэн явагдсан тухай захын хэсэгт бичсэн тэмдэглэлүүд юм. Би бүрэн бүтэн байдал эсвэл техникийн дэлгэрэнгүй мэдээллийг шаарддаггүй; магадгүй тэд өөр нийтлэлд гарч ирэх болно.
Суурь мэдээлэл + энэ ямар төрлийн функц вэ?
Бид үүлэн платформ байгуулж байна (MCS), би техникийн захирлаар ажилладаг. Одоо манай платформ дээр IAM (Identity and Access Management)-ийг нэмэх цаг нь болсон бөгөөд энэ нь бүх хэрэглэгчийн бүртгэл, хэрэглэгчид, нууц үг, үүрэг, үйлчилгээ болон бусад зүйлсийг нэгдсэн удирдлагаар хангадаг. Энэ нь яагаад үүлэнд хэрэгтэй вэ гэдэг нь тодорхой асуулт юм: хэрэглэгчийн бүх мэдээлэл үүнд хадгалагддаг.
Ихэвчлэн ийм зүйл аливаа төслийн хамгийн эхэнд баригдаж эхэлдэг. Гэхдээ түүхийн хувьд MCS-д бүх зүйл арай өөр байсан. MCS хоёр хэсэгт баригдсан:
- Өөрийн Keystone зөвшөөрлийн модультай Openstack,
- Mail.ru Cloud төсөл дээр суурилсан Hotbox (S3 хадгалах сан),
Үүний эргэн тойронд шинэ үйлчилгээнүүд гарч ирэв.
Үндсэндээ эдгээр нь хоёр өөр төрлийн зөвшөөрөл байсан. Нэмж дурдахад, бид Mail.ru-ийн тусдаа боловсруулалтыг ашигласан, жишээлбэл, ерөнхий Mail.ru нууц үг хадгалах газар, мөн өөрөө бичсэн openid холбогч, үүний ачаар Horizon самбар дээр SSO (төгсгөлийн зөвшөөрөл) олгосон. виртуал машинуудын (уугуул OpenStack UI).
Бидний хувьд IAM болгосноор бүгдийг нэг системд, бүрэн өөрсдийнхөө системд холбоно гэсэн үг. Үүний зэрэгцээ бид энэ замд ямар ч функциональ чанараа алдахгүй, харин үүнийг дахин засварлахгүйгээр ил тод болгох, функциональ байдлын хувьд масштаблах боломжийг бидэнд олгох ирээдүйн суурийг бий болгоно. Мөн эхэнд хэрэглэгчид үйлчилгээ (төв RBAC, үүрэгт суурилсан хандалтын хяналт) болон бусад жижиг зүйлсэд хандах үлгэр дуурайлтай байсан.
Даалгавар нь тийм ч энгийн зүйл биш болсон: python болон perl, хэд хэдэн backends, бие даан бичсэн үйлчилгээ, хэд хэдэн хөгжүүлэлтийн баг, админууд. Хамгийн гол нь байлдааны үйлдвэрлэлийн систем дээр олон мянган амьд хэрэглэгчид байдаг. Энэ бүхнийг бичиж, хамгийн чухал нь хохиролгүй гаргах ёстой байв.
Бид юу гаргах гэж байна вэ?
Ойролцоогоор 4 сарын хугацаанд бид дараахь зүйлийг бэлтгэсэн.
- Бид дэд бүтцийн янз бүрийн хэсэгт өмнө нь ажиллаж байсан функцүүдийг нэгтгэсэн хэд хэдэн шинэ демонуудыг бүтээсэн. Үлдсэн үйлчилгээнүүд нь эдгээр чөтгөрүүдийн хэлбэрээр шинэ арын хэсгийг зааж өгсөн.
- Бид өөрсдийн бүх үйлчилгээнд ашиглах боломжтой нууц үг, түлхүүрийн төв хадгаламжийг бичсэн бөгөөд үүнийг хүссэн үедээ чөлөөтэй өөрчлөх боломжтой.
- Бид Keystone-д зориулж эхнээс нь 4 шинэ backend бичсэн (хэрэглэгч, төсөл, үүрэг, үүргийн хуваарилалт) нь үнэндээ өгөгдлийн санг сольсон бөгөөд одоо бидний хэрэглэгчийн нууц үгийн нэг репозитор болж байна.
- Бид бүх Openstack үйлчилгээндээ эдгээр бодлогыг сервер бүрээс локал болгон уншихын оронд гуравдагч талын бодлогын үйлчилгээнд хандахыг заасан (тиймээ, Openstack анхдагч байдлаар ингэж ажилладаг!)
Ийм томоохон дахин боловсруулалт хийх нь янз бүрийн хөгжүүлэлтийн багуудын бичсэн хэд хэдэн системд томоохон, нарийн төвөгтэй, хамгийн чухал нь синхрон өөрчлөлтийг шаарддаг. Угсарсны дараа бүх систем ажиллах ёстой.
Ийм өөрчлөлтийг хэрхэн яаж хийх вэ, мөн үүнийг сүйрүүлэхгүй байх вэ? Эхлээд бид ирээдүйгээ бага зэрэг харахаар шийдсэн.
Дамжуулах стратеги
- Бүтээгдэхүүнийг хэд хэдэн үе шаттайгаар гаргах боломжтой боловч энэ нь боловсруулах хугацааг гурав дахин нэмэгдүүлэх болно. Нэмж дурдахад хэсэг хугацаанд бид мэдээллийн сан дахь өгөгдлийг бүрэн синхрончлохгүй байх болно. Та өөрийн синхрончлолын хэрэгслийг бичиж, олон мэдээллийн сантай удаан хугацаагаар амьдрах хэрэгтэй болно. Мөн энэ нь олон төрлийн эрсдэлийг бий болгодог.
- Хэрэглэгчдэд ил тод бэлтгэж болох бүх зүйлийг урьдчилан хийсэн. 2 сар зарцуулсан.
- Бид өөрсдийгөө хэдэн цагийн турш сул зогсолт хийх боломжийг олгосон - зөвхөн хэрэглэгчийн үйл ажиллагааны нөөцийг бий болгох, өөрчлөхөд зориулагдсан.
- Аль хэдийн бий болсон бүх нөөцийг ажиллуулахын тулд сул зогсолтыг хүлээн зөвшөөрөх боломжгүй байв. Бид нэвтрүүлэх явцад нөөцүүд зогсолтгүй ажиллаж, үйлчлүүлэгчдэд нөлөөлөх ёстой гэж төлөвлөсөн.
- Хэрэв ямар нэг зүйл буруу болвол хэрэглэгчиддээ үзүүлэх нөлөөг багасгахын тулд бид Ням гарагийн орой гаргахаар шийдсэн. Цөөхөн үйлчлүүлэгч шөнийн цагаар виртуал машиныг удирддаг.
- Дамжуулахаар сонгогдсон хугацаанд үйлчилгээний менежмент боломжгүй болно гэдгийг бид бүх үйлчлүүлэгчиддээ анхааруулсан.
Дигресс: танилцуулга гэж юу вэ?
<болгоомж, философи>
Мэдээллийн технологийн мэргэжилтэн бүр танилцуулга гэж юу болохыг хялбархан хариулж чадна. Та CI/CD суулгаж, бүх зүйл автоматаар дэлгүүрт хүргэгдэнэ. 🙂
Мэдээж энэ үнэн. Гэвч хүндрэлтэй тал нь орчин үеийн код хүргэх автоматжуулалтын хэрэгслүүдийн тусламжтайгаар програмын талаарх ойлголт алдагддаг. Орчин үеийн тээврийг харахад дугуйны зохион бүтээсэн баатарлаг байдлын талаар та хэрхэн мартдаг вэ. Бүх зүйл маш автоматжсан тул танилцуулга нь дүр зургийг бүхэлд нь ойлгохгүйгээр ихэвчлэн хийгддэг.
Мөн зураг бүхэлдээ ийм байна. Өргөтгөл нь дөрвөн үндсэн зүйлээс бүрдэнэ.
- Өгөгдлийн өөрчлөлт оруулах зэрэг кодыг хүргэх. Жишээлбэл, тэдний шилжилт хөдөлгөөн.
- Код буцаах нь ямар нэг зүйл буруу болвол буцах чадвар юм. Жишээлбэл, нөөцлөлт үүсгэх замаар.
- Дамжуулах/буцах үйлдэл бүрийн хугацаа. Та эхний хоёр цэгийн аливаа үйлдлийн цагийг ойлгох хэрэгтэй.
- Нөлөөлөлд өртсөн функциональ байдал. Хүлээгдэж буй эерэг болон болзошгүй сөрөг үр дагаврыг үнэлэх шаардлагатай.
Амжилттай нэвтрүүлэхийн тулд эдгээр бүх талыг анхаарч үзэх хэрэгтэй. Ихэвчлэн эхний буюу хамгийн сайндаа хоёр дахь цэгийг үнэлдэг бөгөөд дараа нь нэвтрүүлэлтийг амжилттай гэж үздэг. Гэхдээ гурав, дөрөв дэх нь бүр ч чухал. Дамжуулахад нэг минутын оронд 3 цаг зарцуулсан бол аль хэрэглэгч таалагдах вэ? Эсвэл нэвтрүүлэх явцад шаардлагагүй зүйл нөлөөлсөн бол? Эсвэл нэг үйлчилгээний зогсолт нь урьдчилан таамаглах аргагүй үр дагаварт хүргэх үү?
1..n үйлдэл, суллах бэлтгэл
Эхэндээ би бүхэл бүтэн баг, түүний хэсгүүд, кофены цэгүүд дэх бөөн хэлэлцүүлэг, маргаан, сорилт, тархины шуурга зэрэг уулзалтуудыг товч тайлбарлая гэж бодсон. Дараа нь би үүнийг шаардлагагүй гэж бодсон. Дөрвөн сарын хөгжил үргэлж үүнээс бүрддэг, ялангуяа та байнга хүргэж болох зүйл бичихгүй, харин амьд системд зориулсан нэг том онцлог шинж чанартай байдаг. Энэ нь бүх үйлчилгээнд нөлөөлдөг боловч "вэб интерфэйс дэх нэг товчлуур"-аас бусад тохиолдолд хэрэглэгчдийн хувьд юу ч өөрчлөгдөх ёсгүй.
Хэрхэн нэвтрүүлэх тухай бидний ойлголт шинэ уулзалт бүрээс эрс өөрчлөгдсөн. Жишээлбэл, бид төлбөрийн мэдээллийн санг бүхэлд нь шинэчлэх гэж байсан. Гэхдээ бид цаг хугацааг тооцоолж, боломжийн хугацаанд үүнийг хийх боломжгүй гэдгийг ойлгосон. Тооцооны мэдээллийн санг задлах, архивлахад бид бараг долоо хоног зарцуулсан. Хүлээгдэж буй эргэлтийн хурд хангалтгүй хэвээр байх үед бид суурийг бүхэлд нь чирсэн нэмэлт, илүү хүчирхэг тоног төхөөрөмж захиалсан. Энэ нь бид үүнийг эрт хийхийг хүсээгүй юм биш, гэхдээ одоо ашиглах хэрэгцээ шаардлага бидэнд ямар ч сонголт үлдээгээгүй.
Бидний хэн нэг нь нээлт нь манай виртуал машинуудын хүртээмжид нөлөөлж болзошгүй гэдэгт эргэлзэхэд бид долоо хоногийн турш туршилт, туршилт, кодын дүн шинжилгээ хийж, манай үйлдвэрлэлд ийм зүйл тохиолдохгүй гэдгийг тодорхой ойлгосон бөгөөд хамгийн эргэлзээтэй хүмүүс ч гэсэн үүнийг хүлээн зөвшөөрсөн. үүнтэй хамт.
Энэ хооронд техникийн дэмжлэгийн залуус хэрэглэгчдэд зориулсан холболтын аргын зааварчилгааг бичихийн тулд бие даасан туршилт хийсэн бөгөөд энэ нь нэвтрүүлсний дараа өөрчлөгдөх ёстой байв. Тэд хэрэглэгчийн UX дээр ажиллаж, зааварчилгаа бэлтгэж, хувийн зөвлөгөө өгсөн.
Бид боломжит бүх нэвтрүүлэх ажиллагааг автоматжуулсан. Үйл ажиллагаа бүрийг, тэр ч байтугай хамгийн энгийнийг нь хүртэл скриптээр бичиж, туршилтуудыг байнга явуулдаг байв. Тэд үйлчилгээгээ унтраах хамгийн сайн арга - демоныг орхих эсвэл галт ханаар үйлчилгээнд нэвтрэх эрхийг хаах талаар маргасан. Бид танилцуулах үе шат бүрт багуудын хяналтын хуудсыг гаргаж, байнга шинэчилж байсан. Бид бүх танилцуулах ажилд зориулсан Гант графикийг зурж, цаг хугацаатай нь байнга шинэчилж байсан.
Гэх мэт…
Гарахаасаа өмнөх эцсийн үйлдэл
... гарах цаг нь болсон.
Тэдний хэлснээр урлагийн бүтээлийг дуусгах боломжгүй, зөвхөн түүн дээр ажиллаж дуусна. Та бүх зүйлийг олохгүй гэдгээ ойлгож, бүх үндэслэлтэй таамаглал дэвшүүлж, бүх боломжит тохиолдлуудыг гаргаж, бүх чухал алдаануудыг хааж, бүх оролцогчид чадах бүхнээ хийсэн гэдэгт итгэлтэй байх ёстой. Илүү их код гаргах тусам өөрийгөө үүнд итгүүлэхэд хэцүү байх болно (үүнээс гадна бүх зүйлийг урьдчилан харах боломжгүй гэдгийг бүгд ойлгодог).
Гэнэтийн нөлөөлөл, зогсолттой холбоотой хэрэглэгчиддээ учирч болох бүх эрсдлийг нөхөхийн тулд бид чадах бүхнээ хийсэн гэдэгт итгэлтэй байх үед бид нээлтээ хийхэд бэлэн гэж шийдсэн. Өөрөөр хэлбэл, дараахь зүйлээс бусад зүйл буруу болж магадгүй юм.
- Хэрэглэгчийн дэд бүтцэд (бидний хувьд ариун, хамгийн үнэ цэнэтэй) нөлөөлөх,
- Үйл ажиллагаа: нэвтрүүлсний дараа манай үйлчилгээг ашиглах нь өмнөхтэй адил байх ёстой.
Гарч байна
Хоёр өнхрөх, 8 нь саад болохгүй
Бид хэрэглэгчдийн бүх хүсэлтийг 7 цагийн турш зогсоодог. Одоогийн байдлаар бидэнд нэвтрүүлэх төлөвлөгөө болон буцаах төлөвлөгөө аль аль нь байна.
- Нэвтрэх нь өөрөө ойролцоогоор 3 цаг зарцуулдаг.
- Туршилт хийхэд 2 цаг.
- 2 цаг - өөрчлөлтийг буцааж авах боломжтой.
Үйлдэл тус бүрээр нь Гант диаграммыг гаргасан, хэр хугацаа шаардагдах, юу дараалсан, юуг зэрэгцүүлэн хийдэг.
Эхний хувилбаруудын нэг (зэрэгцээ гүйцэтгэлгүй) Гант диаграмын нэг хэсэг. Хамгийн үнэ цэнэтэй синхрончлолын хэрэгсэл
Бүх оролцогчид танилцуулгад өөрсдийн үүрэг, ямар ажил хийх, юуг хариуцах вэ гэдгээ тодорхойлдог. Бид шат бүрийг автоматжуулж, өнхрүүлж, эргүүлж, санал хүсэлтийг цуглуулж, дахин гаргахыг хичээдэг.
Үйл явдлын шастир
Ингээд дөрөвдүгээр сарын 15-ний ням гаригийн 29 цагт 10 хүн ажилдаа ирсэн. Гол оролцогчдоос гадна зарим нь зүгээр л багаа дэмжихээр ирсэн тул тэдэнд онцгой талархал илэрхийлэв.
Манай гол шалгагч амралтанд байгаа гэдгийг дурдах нь зүйтэй. Туршилтгүйгээр нэвтрүүлэх боломжгүй, бид хувилбаруудыг судалж байна. Хамтран ажиллагсад биднийг амралтаас туршиж үзэхийг зөвшөөрч, бүх багийнхнаас асар их талархал хүлээж байна.
00:00. Зогс
Бид хэрэглэгчийн хүсэлтийг зогсоож, техникийн ажил гэсэн самбар өлгөдөг. Хяналт нь хашгирч байгаа ч бүх зүйл хэвийн байна. Унах ёстой зүйлээс өөр зүйл унасан эсэхийг бид шалгадаг. Мөн бид шилжин суурьших ажлыг эхлүүлж байна.
Хүн бүр хэвлэсэн танилцуулах төлөвлөгөөтэй байдаг бөгөөд хэн, ямар мөчид юу хийж байгааг бүгд мэддэг. Үйлдэл бүрийн дараа бид цаг хугацааг хэтрүүлэхгүйн тулд цаг хугацааг шалгаж, бүх зүйл төлөвлөгөөний дагуу явагддаг. Одоогоор танилцуулгад шууд оролцоогүй хүмүүс хамт олондоо саад учруулахгүйн тулд онлайн тоглоом (Xonotic, type 3 quacks) гарган бэлтгэж байна. 🙂
02:00. Гарсан
Тааламжтай гэнэтийн бэлэг - бид мэдээллийн сан болон шилжих скриптүүдийг оновчтой болгосны улмаас нэг цагийн өмнө нэвтрүүлж дуусгасан. Генерал "Газарчихлаа" гэж хашгирав. Бүх шинэ функцууд үйлдвэрлэгдэж байгаа боловч одоогоор зөвхөн бид тэдгээрийг интерфэйс дээр харах боломжтой. Хүн бүр туршилтын горимд орж, бүлэг болгон ангилж, эцэст нь юу болсныг харж эхэлдэг.
Энэ нь тийм ч сайн болсонгүй, бид үүнийг 10 минутын дараа, юу ч холбоогүй эсвэл багийн гишүүдийн төсөлд ажиллахгүй байхад ойлгодог. Шуурхай синхрончлол, бид асуудлаа хэлж, тэргүүлэх чиглэлээ тодорхойлж, багуудад хуваагдан, дибаг хийх ажилд ордог.
02:30. Дөрвөн нүдний эсрэг хоёр том асуудал
Бид хоёр том асуудалтай тулгардаг. Үйлчлүүлэгчид зарим холбогдсон үйлчилгээг харахгүй, түншийн данстай холбоотой асуудал үүснэ гэдгийг бид ойлгосон. Аль аль нь зарим захын тохиолдлуудад шилжих скриптийн төгс бус байдлаас үүдэлтэй. Бид үүнийг одоо засах хэрэгтэй.
Бид үүнийг хамгийн багадаа 4 нүдээр бүртгэсэн асуулга бичдэг. Бид тэдгээрийг үйлдвэрлэлийн өмнөх үе шатанд шалгаж, ажиллаж, юу ч эвдэхгүй эсэхийг шалгадаг. Та өнхрүүлж болно. Үүний зэрэгцээ бид байнгын интеграцийн туршилтыг явуулдаг бөгөөд энэ нь хэд хэдэн асуудлыг илрүүлдэг. Тэд бүгд жижиг боловч тэдгээрийг засах шаардлагатай.
03:00. -2 асуудал +2 асуудал
Өмнөх хоёр том асуудал, бараг бүх жижиг асуудлуудыг зассан. Засварын ажилгүй байгаа бүх хүмүүс дансандаа идэвхтэй ажиллаж, олж мэдсэн зүйлээ мэдээлж байна. Бид ач холбогдол өгч, багуудад хуваарилж, чухал биш зүйлсийг өглөөд үлдээдэг.
Бид дахин туршилт хийж, тэд хоёр шинэ том асуудлыг илрүүлдэг. Үйлчилгээний бүх бодлого зөв ирээгүй тул зарим хэрэглэгчийн хүсэлт зөвшөөрлийг дамжуулдаггүй. Мөн түншийн данстай холбоотой шинэ асуудал. Яаран харцгаая.
03:20. Яаралтай синхрончлол
Нэг шинэ асуудлыг зассан. Хоёрдугаарт, бид яаралтай синхрончлолыг зохион байгуулж байна. Юу болж байгааг бид ойлгож байна: өмнөх нь нэг асуудлыг зассан боловч өөр нэг асуудлыг үүсгэсэн. Бид үүнийг хэрхэн зөв, үр дагаваргүйгээр хийхийг ойлгохын тулд завсарлага авдаг.
03:30. Зургаан нүд
Бүх түншүүдэд бүх зүйл сайн байхын тулд суурийн эцсийн төлөв ямар байх ёстойг бид ойлгож байна. Бид 6 нүдтэй хүсэлтийг бичиж, урьдчилсан үйлдвэрлэлд өнхрүүлж, туршиж, үйлдвэрлэлд зориулж өнхрүүлдэг.
04:00. Бүх зүйл ажиллаж байна
Бүх шалгалтыг давсан, ямар ч ноцтой асуудал харагдахгүй байна. Заримдаа багийн ямар нэг зүйл хэн нэгэнд тохирохгүй тул бид тэр даруй хариу үйлдэл үзүүлдэг. Ихэнх тохиолдолд дохиолол худлаа байдаг. Гэхдээ заримдаа ямар нэг зүйл ирэхгүй эсвэл тусдаа хуудас ажиллахгүй байна. Бид сууж, засах, засах, засах. Тусдаа баг хамгийн сүүлийн том функц болох төлбөр тооцоог эхлүүлж байна.
04:30. Буцах боломжгүй цэг
Буцах боломжгүй цэг ойртож байна, өөрөөр хэлбэл бид ухраад эхэлбэл бидэнд өгсөн сул зогсолтыг биелүүлэхгүй байх цаг ойртож байна. Бүх зүйлийг мэддэг, бүртгэдэг боловч үйлчлүүлэгчдийнхээ мөнгийг хасахаас зөрүүдлэн татгалздаг тооцооны асуудал байдаг. Хувь хүний хуудас, үйлдэл, статус дээр хэд хэдэн алдаа байдаг. Үндсэн функц ажилладаг, бүх тест амжилттай давж байна. Бид танилцуулга хийгдсэн гэж шийдсэн, бид буцаахгүй.
06:00. UI дээрх хүн бүрт нээлттэй
Алдааг зассан. Хэрэглэгчдэд таалагдаагүй заримыг дараа нь үлдээдэг. Бид интерфэйсийг хүн бүрт нээж өгдөг. Бид хэрэглэгчийн санал хүсэлт, хяналтын үр дүнг хүлээж, тооцоо хийх ажлыг үргэлжлүүлсээр байна.
07:00. API ачааллын асуудал
Бид API дээрх ачааллыг бага зэрэг буруу төлөвлөж, энэ ачааллыг туршиж үзсэн нь асуудлыг тодорхойлж чадаагүй нь тодорхой болсон. Үүний үр дүнд хүсэлтийн ≈5% амжилтгүй болсон. Дайчлаад учрыг нь хайцгаая.
Тооцоо хийх нь зөрүүд бөгөөд ажиллахыг хүсдэггүй. Өөрчлөлтийг тайван замаар явуулахын тулд бид үүнийг хожим нь хойшлуулахаар шийдсэн. Өөрөөр хэлбэл, бүх нөөц үүнд хуримтлагдсан боловч үйлчлүүлэгчдээс хасалт хийгддэггүй. Мэдээжийн хэрэг, энэ нь асуудал юм, гэхдээ ерөнхий танилцуулгатай харьцуулахад энэ нь тийм ч чухал биш юм шиг санагддаг.
08:00. API засах
Бид ачааллыг засч залруулж, алдаанууд арилсан. Бид гэртээ харьж эхэлдэг.
10:00. Бүгд
Бүх зүйл тогтсон. Хяналт нь чимээгүй, үйлчлүүлэгчдийн байранд баг аажмаар унтдаг. Төлбөр үлдсэн, бид маргааш сэргээх болно.
Дараа нь өдрийн турш манай зарим үйлчлүүлэгчдэд зориулсан бүртгэл, мэдэгдэл, буцаах код, тохиргоог зассан програмууд байсан.
Тиймээс нээлт амжилттай боллоо! Энэ нь мэдээж илүү дээр байж болох ч төгс төгөлдөрт хүрэхэд юу хангалтгүй байсан талаар бид дүгнэлт хийсэн.
Нийт
Нэвтрүүлэгт идэвхтэй бэлтгэх 2 сарын хугацаанд хоёр цагаас хэдэн өдөр хүртэл үргэлжилсэн 43 ажлыг гүйцэтгэсэн.
Дамжуулах явцад:
- шинэ ба өөрчлөгдсөн чөтгөрүүд - 5 цул солих 2 ширхэг;
- өгөгдлийн сан дахь өөрчлөлтүүд - хэрэглэгчийн өгөгдөл бүхий манай 6 мэдээллийн сан бүгд нөлөөлсөн, гурван хуучин мэдээллийн сангаас нэг шинэ мэдээллийн санд татан авалт хийгдсэн;
- бүрэн шинэчилсэн нүүрэн тал;
- татаж авсан кодын хэмжээ - 33 мянган мөр шинэ код, ≈ тестийн 3 мянган мөр код, ≈ 5 мянган мөр шилжих код;
- бүх өгөгдөл бүрэн бүтэн, нэг ч хэрэглэгчийн виртуал машин гэмтээгүй. 🙂
Сайн нэвтрүүлэх сайн туршлагууд
Тэд биднийг энэ хүнд нөхцөлд удирдан чиглүүлсэн. Гэхдээ ерөнхийдөө аливаа сурталчилгааны үеэр тэдгээрийг дагаж мөрдөх нь ашигтай байдаг. Гэхдээ танилцуулга нь илүү төвөгтэй байх тусам тэдний гүйцэтгэх үүрэг их байх болно.
- Таны хийх ёстой хамгийн эхний зүйл бол танилцуулга нь хэрэглэгчдэд хэрхэн нөлөөлж болохыг ойлгох явдал юм. Сул зогсолт гарах уу? Хэрэв тийм бол сул зогсолт гэж юу вэ? Энэ нь хэрэглэгчдэд хэрхэн нөлөөлөх вэ? Боломжит хамгийн сайн ба хамгийн муу хувилбарууд юу вэ? Мөн эрсдэлийг даах.
- Бүх зүйлийг төлөвлө. Үе шат бүрт та нэвтрүүлэх бүх талыг ойлгох хэрэгтэй:
- код хүргэх;
- кодыг буцаах;
- үйл ажиллагаа бүрийн цаг хугацаа;
- нөлөөлөлд өртсөн функциональ байдал.
- Програмын бүх үе шатууд, түүнчлэн тэдгээрийн эрсдэлүүд тодорхой болох хүртэл хувилбаруудыг тоглоорой. Хэрэв танд эргэлзэж байвал завсарлага аваад эргэлзээтэй үе шатыг тусад нь шалгаж болно.
- Үе шат бүр нь хэрэглэгчдэдээ тустай бол сайжруулж болно. Жишээлбэл, энэ нь сул зогсолтыг багасгах эсвэл зарим эрсдлийг арилгах болно.
- Буцах тест нь код дамжуулах тестээс хамаагүй чухал юм. Буцах ажиллагааны үр дүнд систем анхны төлөвтөө буцаж ирэх эсэхийг шалгаж, туршилтаар баталгаажуулах шаардлагатай.
- Автоматжуулж болох бүх зүйлийг автоматжуулах хэрэгтэй. Автоматжуулах боломжгүй бүх зүйлийг хууран мэхлэх хуудсан дээр урьдчилан бичсэн байх ёстой.
- Амжилтын шалгуурыг тэмдэглэ. Ямар функц, ямар үед бэлэн байх ёстой вэ? Хэрэв ийм зүйл болохгүй бол буцаах төлөвлөгөөг ажиллуул.
- Хамгийн гол нь - хүмүүс. Хүн бүр юу хийж байгаагаа мэддэг байх ёстой, яагаад, юу хийх нь тэдний үйл ажиллагаанаас хамаардаг.
Нэг өгүүлбэрт сайн төлөвлөлт, боловсруулалт хийснээр та хүссэн бүхнээ борлуулалтад үр дагаваргүйгээр гаргаж болно. Тэр ч байтугай ямар нэгэн зүйл үйлдвэрлэлд таны бүх үйлчилгээнд нөлөөлөх болно.
Эх сурвалж: www.habr.com