Banki.ru порталын үйл ажиллагааны захирал Андрей Никольский өнгөрсөн жилийн хурал дээр үг хэлэв өнчин хүүхдийн үйлчилгээний талаар: дэд бүтцэд байгаа өнчин хүүхдийг хэрхэн тодорхойлох, яагаад өнчин хүүхдийн үйлчилгээ муу байдаг, тэдэнтэй юу хийх, юу ч тус болохгүй бол яах вэ.
Тайлангийн доор текстийн хувилбар байна.
Сайн байна уу хамт олон! Намайг Андрей гэдэг, би Banki.ru сайтын үйл ажиллагааг удирддаг.
Манайд томоохон үйлчилгээ байдаг, эдгээр нь ийм цул үйлчилгээнүүд, илүү сонгодог утгаараа үйлчилгээ байдаг, маш жижиг үйлчилгээ байдаг. Ажилчин тариачны нэр томьёогоор бол үйлчилгээ нь энгийн, жижиг бол микро, тийм ч энгийн, жижиг биш бол зүгээр л үйлчилгээ гэж хэлдэг.
Үйлчилгээний давуу тал
Би үйлчилгээний давуу талуудын талаар хурдан ярих болно.
Эхнийх нь масштаблах явдал юм. Та үйлчилгээн дээр ямар нэг зүйлийг хурдан хийж, үйлдвэрлэлээ эхлүүлэх боломжтой. Та траффик хүлээн авлаа, та үйлчилгээг хувилсан байна. Танд илүү их ачаалал байна, та үүнийг хувилаад, түүнтэй хамт амьдардаг. Энэ бол сайн урамшуулал бөгөөд зарчмын хувьд бид үүнийг эхлүүлэхэд бидний хувьд хамгийн чухал зүйл гэж үздэг байсан, яагаад бид энэ бүгдийг хийж байна.
Хоёрдугаарт, тусгаарлагдсан хөгжүүлэлт, хэрэв та хэд хэдэн хөгжүүлэлтийн багтай, баг бүрт хэд хэдэн өөр өөр хөгжүүлэгчид, баг бүр өөр өөрийн үйлчилгээг хөгжүүлдэг.
Багуудын хувьд нэг нюанс байдаг. Хөгжүүлэгчид өөр өөр байдаг. Мөн байдаг, жишээлбэл, . Би үүнийг Максим Дорофеевтэй анх харсан. Заримдаа цасан ширхгүүд зарим багт байдаг бол заримд нь байдаггүй. Энэ нь компани даяар хэрэглэгддэг өөр өөр үйлчилгээг арай жигд бус болгодог.
Зургийг хараарай: энэ бол сайн хөгжүүлэгч, тэр том гартай, маш их зүйлийг хийж чадна. Хамгийн гол асуудал бол эдгээр гарууд хаанаас гардаг вэ?
Үйлчилгээнүүд нь янз бүрийн даалгаварт илүү тохиромжтой өөр өөр програмчлалын хэлийг ашиглах боломжийг олгодог. Зарим үйлчилгээ нь Go, зарим нь Erlang, зарим нь Ruby, зарим нь PHP, зарим нь Python дээр байдаг. Ерөнхийдөө та маш өргөн хүрээг тэлж чадна. Энд бас нюансууд бий.
Үйлчилгээнд чиглэсэн архитектур нь үндсэндээ devops-тэй холбоотой. Өөрөөр хэлбэл, хэрэв танд автоматжуулалт байхгүй бол байршуулах процесс байхгүй, хэрэв та үүнийг гараар тохируулбал таны тохиргоо үйлчилгээний жишээнээс инстант руу өөрчлөгдөж, ямар нэг зүйл хийхийн тулд тийшээ очих хэрэгтэй, тэгвэл та тамд байна.
Жишээлбэл, танд 20 үйлчилгээ байгаа бөгөөд та гараар байршуулах хэрэгтэй, танд 20 консол байгаа бөгөөд та нинжа шиг "enter" товчийг нэгэн зэрэг дарна уу. Энэ нь тийм ч сайн биш юм.
Хэрэв танд туршилтын дараа үйлчилгээ байгаа бол (мэдээж туршилт байгаа бол) үүнийг үйлдвэрлэлд ажиллуулахын тулд файлаар дуусгах шаардлагатай бол би танд бас муу мэдээ байна.
Хэрэв та Амазоны тодорхой үйлчилгээнд найдаж, Орост ажилладаг бол хоёр сарын өмнө "Эргэн тойронд бүх зүйл шатаж байна, би зүгээр, бүх зүйл сайхан байна" гэж байсан.
Бид байршуулалтыг автоматжуулахын тулд Ansible, нэгдэхийн тулд Puppet, байршуулалтыг автоматжуулахын тулд Bamboo, Confluence-ийг бүгдийг нь ямар нэгэн байдлаар дүрслэхийн тулд ашигладаг.
Тайлан нь техникийн хэрэгжилтийн талаар бус харин харилцан үйлчлэлийн практикийн талаар илүү их ярьдаг тул би энэ талаар дэлгэрэнгүй ярихгүй.
Жишээлбэл, сервер дээрх хүүхэлдэй нь Ruby 2-той ажиллахад асуудалтай тулгарсан боловч зарим програмыг Ruby 1.8-д зориулж бичсэн бөгөөд тэд хамтдаа ажилладаггүй. Тэнд ямар нэг зүйл буруу болж байна. Мөн та нэг машин дээр Ruby-ийн олон хувилбарыг ажиллуулах шаардлагатай үед ихэвчлэн асуудалтай тулгардаг.
Жишээлбэл, бид хөгжүүлэгч бүрт өөрт байгаа бараг бүх зүйл, хөгжүүлж болох бүх үйлчилгээ байдаг платформыг өгдөг бөгөөд ингэснээр тусгаарлагдсан орчинтой, тэр үүнийг эвдэж, хүссэнээрээ барьж чадна.
Тэнд ямар нэг зүйлийг дэмжих тусгайлан эмхэтгэсэн багц хэрэгтэй болдог. Энэ нь нэлээд хатуу юм. Би Docker дүрс 45 ГБ жинтэй тайланг сонссон. Линукс дээр мэдээжийн хэрэг илүү энгийн, бүх зүйл жижиг, гэхдээ хангалттай зай байхгүй болно.
Төслийн нэг хэсэг нь нэг хувилбарын номын сангаас, нөгөө хэсэг нь өөр хувилбараас шалтгаалж, номын сангууд нь хамтад нь огт суулгагдаагүй байхад зөрчилдөөнтэй хамаарал бий.
Бидэнд PHP 5.6 дээр байгаа сайтууд, үйлчилгээнүүд байгаа, бид тэднээс ичиж байна, гэхдээ бид юу хийж чадах вэ? Энэ бол манай нэг сайт. PHP 7 дээр сайтууд, үйлчилгээнүүд байдаг, тэднээс илүү олон байдаг, бид тэднээс ичдэггүй. Хөгжүүлэгч бүр өөрийн гэсэн суурьтай байдаг бөгөөд тэндээ аз жаргалтайгаар хөрөөддөг.
Хэрэв та компанид нэг хэлээр бичвэл хөгжүүлэгч бүрт гурван виртуал машин байх нь хэвийн сонсогддог. Хэрэв та өөр өөр програмчлалын хэлтэй бол нөхцөл байдал улам дордох болно.
Танд энэ талаар сайтууд болон үйлчилгээнүүд байна, үүн дээр, дараа нь Go-д зориулсан өөр сайт, Ruby-д зориулсан нэг сайт, хажуу талд нь бусад Redis-ууд байна. Үүний үр дүнд энэ бүхэн дэмжлэг үзүүлэх том талбар болж хувирдаг бөгөөд үргэлж зарим нь эвдэрч болно.
Тиймээс бид програмчлалын хэлний давуу талыг өөр өөр фреймворк ашиглан сольсон, учир нь PHP хүрээ нь тэс өөр, өөр өөр чадвартай, өөр өөр нийгэмлэг, өөр өөр дэмжлэгтэй байдаг. Та үйлчилгээ бичиж болно, ингэснээр танд ямар нэгэн зүйл бэлэн байна.
Үйлчилгээ бүр өөрийн гэсэн багтай
Хэдэн жилийн турш талссан бидний гол давуу тал бол үйлчилгээ бүр өөрийн гэсэн багтай байдаг. Энэ нь том төсөлд тохиромжтой, та баримт бичигт цаг хэмнэх боломжтой, менежерүүд төслөө сайн мэддэг.
Та дэмжлэгээс даалгавраа хялбархан илгээх боломжтой. Тухайлбал, даатгалын үйлчилгээ доголдсон. Тэгээд тэр даруй даатгалтай холбоотой баг үүнийг засахаар явдаг.
Шинэ боломжууд хурдан бий болж байна, учир нь танд нэг атомын үйлчилгээ байгаа үед та ямар нэг зүйлийг хурдан оруулах боломжтой.
Та үйлчилгээгээ эвдэж, энэ нь зайлшгүй тохиолдох үед та бусдын үйлчилгээнд нөлөөлөөгүй бөгөөд бусад багийн хөгжүүлэгчид чам руу гүйж ирээд: "Өө, битгий ингэ" гэж хэлдэггүй.
Ердийнх шиг нюансууд байдаг. Бид тогтвортой багтай, менежерүүд багт хадагдсан. Тодорхой бичиг баримтууд байдаг, менежерүүд бүх зүйлийг сайтар хянаж байдаг. Менежертэй баг бүр хэд хэдэн үйлчилгээтэй бөгөөд тодорхой чадамжтай байдаг.
Хэрэв багууд хөвж байвал (бид үүнийг заримдаа ашигладаг) "од газрын зураг" гэж нэрлэгддэг сайн арга байдаг.
Танд үйлчилгээ, хүмүүсийн жагсаалт байна. Од гэдэг нь тухайн хүн энэ үйлчилгээний мэргэжилтэн, ном гэдэг нь тухайн хүн энэ үйлчилгээг судалж байна гэсэн үг. Хүний даалгавар бол товхимолыг одоор солих явдал юм. Үйлчилгээний өмнө юу ч бичээгүй бол асуудал эхэлдэг бөгөөд энэ талаар би цаашид ярих болно.
Өнчин хүүхдийн үйлчилгээ хэрхэн гарч ирдэг вэ?
Эхний асуудал, дэд бүтцээрээ өнчин үйлчилгээ авах эхний арга бол хүмүүсийг халах явдал юм. Даалгавруудыг үнэлэхээс өмнө бизнестэй уулзах хугацаатай байсан хүн бий юу? Заримдаа эцсийн хугацаа хатуу, бичиг баримт бүрдүүлэхэд хангалттай хугацаа байдаггүй. "Бид үйлчилгээг үйлдвэрлэлд хүлээлгэж өгөх хэрэгтэй, дараа нь бид үүнийг нэмнэ."
Хэрэв баг жижиг бол бүх зүйлийг бичдэг нэг хөгжүүлэгч байдаг, бусад нь далавчинд байдаг. "Би үндсэн архитектурыг бичсэн, интерфэйсүүдийг нэмье." Дараа нь зарим үед менежер, жишээлбэл, орхидог. Энэ хугацаанд менежер явсан бөгөөд шинээр томилогдоогүй байгаа үед үйлчилгээ хаашаа явж, тэнд юу болж байгааг хөгжүүлэгчид өөрсдөө шийддэг. Бидний мэдэж байгаагаар (хэд хэдэн слайд руу буцъя) зарим багуудад цасан ширхгүүд, заримдаа цасан ширхгийн багийн ахлагч байдаг. Дараа нь тэр ажлаасаа гарч, бид өнчин хүүхдийн үйлчилгээ авдаг.
Үүний зэрэгцээ, дэмжлэг, бизнесийн даалгавар алга болдоггүй, харин хоцрогдолд ордог. Үйлчилгээг хөгжүүлэх явцад ямар нэгэн архитектурын алдаа гарсан бол тэд бас хоцрогдолд ордог. Үйлчилгээ нь аажмаар муудаж байна.
Өнчин хүүхдийг яаж тодорхойлох вэ?
Энэ жагсаалт нь нөхцөл байдлыг маш сайн тодорхойлсон. Тэдний дэд бүтцийн талаар хэн юу ч сурсан бэ?
Баримтжуулсан ажлын тойргийн тухай: үйлчилгээ байдаг бөгөөд ерөнхийдөө энэ нь ажилладаг, үүнтэй хэрхэн ажиллах талаар хоёр хуудас гарын авлагатай байдаг, гэхдээ энэ нь дотроо хэрхэн ажилладагийг хэн ч мэдэхгүй.
Эсвэл, жишээ нь, ямар нэгэн холбоос богиносгогч байдаг. Жишээлбэл, бид одоогоор өөр өөр үйлчилгээнүүдэд өөр өөр зорилгоор ашигладаг гурван холбоос богиносгогчтой. Эдгээр нь зөвхөн үр дагавар юм.
Одоо би илтийн ахмад байх болно. Юу хийх ёстой вэ? Нэгдүгээрт, бид үйлчилгээг өөр менежер, өөр багт шилжүүлэх хэрэгтэй. Хэрэв танай багийн ахлагч ажлаасаа гарч амжаагүй байгаа бол энэ бусад багт, энэ үйлчилгээ нь өнчин хүүхэд шиг гэдгийг ойлгох үед та энэ талаар ядаж ямар нэг зүйлийг ойлгодог хүнийг оруулах хэрэгтэй.
Хамгийн гол нь та цусаар бичигдсэн шилжүүлгийн журамтай байх ёстой. Манай тохиолдолд би үүнийг ихэвчлэн хянадаг, учир нь надад энэ бүхэн хэрэгтэй. Менежерүүдэд үүнийг хурдан хүргэх хэрэгтэй бөгөөд дараа нь юу тохиолдох нь тэдэнд тийм ч чухал биш болсон.
Өнчин хүүхэд болгох дараагийн арга бол "Бид үүнийг аутсорсингоор хийнэ, энэ нь илүү хурдан байх болно, дараа нь бид үүнийг багтаа хүлээлгэж өгөх болно." Хүн бүр багт ямар нэгэн төлөвлөгөө, эргэлт байгаа нь тодорхой байна. Ихэнхдээ бизнесийн үйлчлүүлэгч аутсорсинг компанид байгаа техникийн хэлтэстэй ижил зүйлийг хийх болно гэж боддог. Хэдийгээр тэдний өдөөгч нь өөр өөр байдаг. Аутсорсингийн хувьд хачирхалтай технологийн шийдлүүд, хачирхалтай алгоритмын шийдлүүд байдаг.
Жишээлбэл, бид янз бүрийн гэнэтийн газруудад сфинкстэй үйлчилгээ үзүүлдэг байсан. Би юу хийх ёстойгоо дараа хэлье.
Аутсорсерууд өөрсдөө бичсэн хүрээтэй байдаг. Энэ бол өмнөх төслөөс хуулж буулгасан нүцгэн PHP бөгөөд эндээс та бүх төрлийн зүйлийг олж болно. Зарим файлын хэд хэдэн мөрийг өөрчлөхийн тулд зарим нарийн төвөгтэй Bash скриптүүдийг ашиглах шаардлагатай үед байршуулах скрипт нь том дутагдалтай тал бөгөөд эдгээр байршуулалтын скриптүүдийг зарим гуравдагч скриптээр дууддаг. Үүний үр дүнд та байршуулах системийг өөрчилж, өөр зүйл сонгоод, үсрэх боловч таны үйлчилгээ ажиллахгүй байна. Учир нь тэнд өөр өөр хавтас хооронд 8 холбоос оруулах шаардлагатай болсон. Эсвэл мянган бичлэг ажилладаг ч зуун мянга нь ажиллахаа больсон тохиолдол гардаг.
Би ахлагчаа үргэлжлүүлнэ. Аутсорсингийн үйлчилгээг хүлээн авах нь заавал байх ёстой журам юм. Хэн нэгэн аутсорсингийн үйлчилгээ ирж, хаана ч хүлээж авахгүй байсан уу? Энэ нь мэдээжийн хэрэг, өнчин хүүхдийн үйлчилгээ шиг алдартай биш боловч одоо ч гэсэн.
Үйлчилгээг шалгах, үйлчилгээг шалгах, нууц үгээ өөрчлөх шаардлагатай. Тэд бидэнд үйлчилгээ үзүүлэхэд бид "хэрэв нэвтрэх == 'админ' && нууц үг == 'админ'..." гэсэн админ самбар байдаг, энэ нь кодонд шууд бичигдсэн байдаг. Бид суугаад бодож, хүмүүс 2018 онд үүнийг бичдэг үү?
Хадгалах багтаамжийг турших нь бас зайлшгүй шаардлагатай зүйл юм. Та энэ үйлчилгээг хаа нэг газар үйлдвэрлэхээс өмнө зуун мянган бичлэг дээр юу тохиолдохыг харах хэрэгтэй.
Сайжруулахын тулд үйлчилгээг илгээх нь ичгүүртэй байх ёсгүй. Та: "Бид энэ үйлчилгээг хүлээж авахгүй, бидэнд 20 даалгавар байна, тэдгээрийг хий, тэгвэл бид хүлээн авна" гэж хэлэхэд энэ нь хэвийн зүйл юм. Менежер томилж байна, эсвэл бизнес нь мөнгө үрж байна гэж таны ухамсрыг гэмтээж болохгүй. Дараа нь бизнес илүү их мөнгө зарцуулах болно.
Бид туршилтын төслийг аутсорсинг хийхээр шийдсэн тохиолдол гарсан.
Энэ нь цагтаа хүргэгдсэн бөгөөд энэ нь чанарын цорын ганц шалгуур байсан юм. Тийм ч учраас бид туршилт хийхээ больсон өөр нэг туршилтын төсөл хийсэн. Эдгээр үйлчилгээг хүлээн зөвшөөрсөн бөгөөд захиргааны арга замаар тэд энд таны код, энд баг, энд танай менежер гэж хэлсэн. Үйлчилгээнүүд нь үнэндээ аль хэдийн ашиг олж эхэлсэн. Үүний зэрэгцээ үнэн хэрэгтээ тэд өнчин хэвээр байгаа бөгөөд тэдний хэрхэн ажилладагийг хэн ч ойлгодоггүй бөгөөд менежерүүд тэдний даалгаварыг үл тоомсорлохын тулд чадах бүхнээ хийдэг.
Өөр нэг гайхалтай ойлголт байдаг - партизаны хөгжил. Зарим хэлтэс, ихэвчлэн маркетингийн алба нь таамаглалыг туршиж үзэхийг хүсч, бүх үйлчилгээг аутсорсингоор захиалах үед. Түүнд хөл хөдөлгөөн орж эхэлдэг, тэд бичиг баримтаа хааж, гэрээлэгчтэй гарын үсэг зурж, ашиглалтад орж ирээд: "Залуус аа, манай энд үйлчилгээ байна, энэ нь ачаалалтай байна, энэ нь бидэнд мөнгө авчирдаг, үүнийг хүлээн авъя" гэж хэлдэг. Бид "Оппа, яаж ийм байж болох юм" гэж байсан.
Мөн өнчин хүүхдийн үйлчилгээ авах өөр нэг арга: зарим баг гэнэт ачаалалтай болоход удирдлага нь "Энэ багийн үйлчилгээг өөр багт шилжүүлье, ачаалал бага байна" гэж хэлдэг. Тэгээд бид үүнийг гуравдагч багт шилжүүлж, менежерээ солих болно. Тэгээд эцэст нь дахиад л өнчин хүүхэдтэй болсон.
Өнчин хүүхдүүдийн асуудал юу вэ?
Энэ бол Шведэд босгосон Васа хэмээх байлдааны хөлөг онгоц бөгөөд хөөрснөөс хойш 5 минутын дараа живсэн гэдгээрээ алдартай. Дашрамд хэлэхэд Шведийн хаан үүний төлөө хэнийг ч цаазлаагүй. Ийм хөлөг онгоц бүтээхийг мэддэггүй хоёр үеийн инженерүүд үүнийг барьсан. Байгалийн нөлөө.
Дашрамд хэлэхэд хөлөг онгоц илүү муу байдлаар живж магадгүй байсан, жишээлбэл, хаан аль хэдийн хаа нэгтээ шуурганд унаж байх үед. Тиймээс тэр даруй живсэн, Agile-ийн хэлснээр эрт бүтэлгүйтэх нь сайн хэрэг.
Хэрэв бид эрт амжилтгүй болвол ихэвчлэн ямар ч асуудал гардаггүй. Жишээлбэл, хүлээн авахдаа дахин хянан үзэхээр явуулсан. Гэхдээ бид хэдийнэ үйлдвэрлэлээ бүтэлгүйтсэн бол мөнгө хөрөнгө оруулалт хийснээр асуудал үүсч магадгүй юм. Үр дагавар гэж бизнест нэрлэдэг.
Өнчин үйлчилгээ яагаад аюултай вэ?
- Үйлчилгээ гэнэт эвдэрч магадгүй.
- Үйлчилгээ нь засвар хийхэд удаан хугацаа шаардагддаг эсвэл огт засваргүй байдаг.
- Аюулгүй байдлын асуудал.
- Сайжруулалт, шинэчлэлттэй холбоотой асуудлууд.
- Чухал үйлчилгээ эвдэрвэл компанийн нэр хүнд унана.
Өнчин хүүхдийн үйлчилгээг юу хийх вэ?
Би юу хийхээ дахин хэлье. Нэгдүгээрт, баримт бичиг байх ёстой. Banki.ru-д 7 жил ажилласнаар тестерүүд хөгжүүлэгчдийн үгийг хүлээж авах ёсгүй, үйл ажиллагаа нь хүн бүрийн үгийг хүлээж авах ёсгүй гэдгийг надад заасан. Бид шалгах хэрэгтэй.
Хоёрдугаарт, харилцан үйлчлэлийн диаграм бичих шаардлагатай, учир нь тийм ч сайн хүлээн аваагүй үйлчилгээнд хэн ч хэлээгүй хамаарлыг агуулсан байдаг. Жишээлбэл, хөгжүүлэгчид энэ үйлчилгээг Yandex.Maps эсвэл Dadata-ийн түлхүүр дээр суулгасан. Таны чөлөөт хязгаар дууссан, бүх зүйл эвдэрсэн, юу болсныг та огт мэдэхгүй. Ийм бүх тармуурыг тайлбарлах ёстой: үйлчилгээ нь Dadata, SMS, өөр зүйлийг ашигладаг.
Гуравдугаарт, техникийн өртэй ажиллаж байна. Та ямар нэгэн төрлийн суга таяг хийх юм уу үйлчилгээг хүлээж аваад ямар нэг зүйл хийх хэрэгтэй гэж хэлэхэд та үүнийг хийсэн эсэхийг шалгах хэрэгтэй. Учир нь тэр үед жижиг нүх нь тийм ч жижиг биш болж магадгүй бөгөөд та түүгээр унах болно.
Архитектурын даалгаврын дагуу бид Сфинксийн тухай түүхтэй байсан. Үйлчилгээнүүдийн нэг нь жагсаалт оруулахдаа Сфинксийг ашигласан. Зүгээр л хуудасласан жагсаалт, гэхдээ орой болгон дахин индексжүүлдэг байсан. Үүнийг хоёр индексээс цуглуулсан: нэг том индексийг орой бүр индексжүүлдэг, мөн жижиг индекстэй байсан. Өдөр бүр 50% -ийн магадлалтай бөмбөгдөлтөнд өртөх магадлалтай байсан ч тооцооллын явцад индекс унасан тул манай мэдээ үндсэн хуудсан дээр шинэчлэгдэхээ больсон. Эхлээд индексийг дахин индексжүүлэхэд 5 минут зарцуулсан бол дараа нь индекс өсч, зарим үед дахин индексжүүлэхэд 40 минут зарцуулагдаж эхэлсэн. Бид үүнийг таслах үед бага зэрэг хугацаа өнгөрч, манай индекс бүтэн цагаар дахин индексжих нь тодорхой байсан тул бид тайван амьсгалсан. Энэ нь манай порталын хувьд бүтэлгүйтэх болно, найман цагийн турш мэдээ алга - тэгээд л бизнес зогссон.
Өнчин хүүхдийн үйлчилгээтэй ажиллах төлөвлөгөө
Үнэн хэрэгтээ үүнийг хийхэд маш хэцүү байдаг, учир нь devops нь харилцааны тухай юм. Та хамт ажиллагсадтайгаа сайн харилцаатай байхыг хүсч байгаа бөгөөд хамт ажиллагсад болон менежерүүдээ дүрэм журмын дагуу цохиход тэд үүнийг хийдэг хүмүүст зөрчилдөж магадгүй юм.
Эдгээр бүх цэгүүдээс гадна өөр нэг чухал зүйл бий: тодорхой хүмүүс байршуулах журмын тодорхой хэсэг бүрийг тодорхой үйлчилгээ тус бүрийг хариуцах ёстой. Хүмүүс байхгүй, та энэ асуудлыг бүхэлд нь судлахын тулд өөр хүмүүсийг татах шаардлагатай бол энэ нь хэцүү болно.
Хэрэв энэ бүхэн тус болоогүй бөгөөд таны өнчин үйлчилгээ өнчин хэвээр байгаа бол хэн ч үүнийг авахыг хүсэхгүй, бичиг баримт бичигдээгүй, энэ үйлчилгээнд дуудагдсан баг юу ч хийхээс татгалзвал энгийн арга бий - дахин хийх. бүх зүйл.
Өөрөөр хэлбэл, та үйлчилгээний шаардлагыг шинээр авч, хачирхалтай технологийн шийдэлгүйгээр шинэ үйлчилгээг илүү сайн, илүү сайн платформ дээр бичих болно. Мөн та тулалдаанд түүн рүү нүүж очдог.
Yii 1 дээр сайн бичдэг хөгжүүлэгч дутсан тул бид Yii 1 дээр үйлчилгээ аваад цаашид хөгжүүлж чадахгүйгээ ойлгосон нөхцөл байдал үүссэн. Бүх хөгжүүлэгчид Symfony XNUMX дээр сайн бичдэг. Юу хийх вэ? Бид цаг гаргаж, баг хуваарилж, менежерээ хуваарилж, төслийг дахин бичиж, замын хөдөлгөөнийг түүн рүү жигд шилжүүлэв.
Үүний дараа хуучин үйлчилгээг устгаж болно. Энэ бол миний хамгийн дуртай процедур бөгөөд та тохиргооны удирдлагын системээс зарим үйлчилгээг авч, цэвэрлэж, дараа нь үйлдвэрлэж буй бүх машинууд идэвхгүй болсон эсэхийг харах хэрэгтэй бөгөөд ингэснээр хөгжүүлэгчид ямар ч ул мөр үлдээхгүй. Хадгалах газар Git-д хэвээр байна.
Энэ бол миний ярихыг хүссэн бүх зүйл, би хэлэлцэхэд бэлэн байна, сэдэв бол Холивар, олон хүн үүнд сэлж байсан.
Слайд дээр та хэлийг нэгтгэсэн гэж хэлсэн. Жишээ нь зургийн хэмжээг өөрчлөх явдал байв. Үүнийг нэг хэлээр хатуу хязгаарлах шаардлагатай юу? Учир нь PHP дээр зургийн хэмжээг өөрчлөх ажлыг Голанг хэл дээр хийж болно.
Үнэн хэрэгтээ энэ нь бүх практикийн нэгэн адил сонголттой байдаг. Магадгүй, зарим тохиолдолд энэ нь бүр хүсээгүй юм. Гэхдээ та 50 хүний бүрэлдэхүүнтэй компанид техникийн хэлтэстэй бол тэдний 45 нь PHP-ийн мэргэжилтэн, өөр 3 нь Python, Ansible, Puppet гэх мэт зүйлийг мэддэг devops, зөвхөн нэг нь зарим хэл дээр бичдэг гэдгийг ойлгох хэрэгтэй. Зарим Go зургийн хэмжээг өөрчлөх үйлчилгээ, дараа нь түүнийг орхих үед мэргэжлийн ур чадвар дагалдана. Үүний зэрэгцээ та энэ хэлийг мэддэг, ялангуяа ховор тохиолдолд зах зээлд тохирсон хөгжүүлэгч хайх хэрэгтэй болно. Өөрөөр хэлбэл, зохион байгуулалтын үүднээс авч үзвэл энэ нь асуудалтай юм. Devops-ийн үүднээс авч үзвэл, та үйлчилгээгээ ашиглахад ашигладаг бэлэн тоглоомын багцыг хуулбарлах шаардлагагүй, гэхдээ та бүгдийг дахин бичих хэрэгтэй болно.
Бид одоогоор Node.js дээр үйлчилгээ бүтээж байгаа бөгөөд энэ нь хөгжүүлэгч бүрийн хувьд тусдаа хэлтэй ойролцоох платформ байх болно. Гэхдээ бид лааны үнэ цэнэтэй тоглоом гэж бодож суулаа. Энэ бол та суугаад бодох асуулт юм.
Та үйлчилгээндээ хэрхэн хяналт тавьдаг вэ? Бүртгэлийг хэрхэн цуглуулж, хянадаг вэ?
Бид Elasticsearch-д лог цуглуулж, Кибана-д тавьдаг бөгөөд энэ нь үйлдвэрлэлийн эсвэл туршилтын орчин эсэхээс хамаарч өөр өөр коллекторуудыг ашигладаг. Хаа нэг Модчин, хаа нэгтээ өөр зүйл, би санахгүй байна. Зарим үйлчилгээнд Telegraf суулгаж, өөр газар тусад нь бууддаг газрууд байсаар байна.
Хүүхэлдэй, Ансибл хоёртой нэг орчинд яаж амьдрах вэ?
Үнэн хэрэгтээ бид одоо хоёр орчинтой болсон, нэг нь Хүүхэлдэй, нөгөө нь Ansible. Бид тэднийг эрлийзжүүлэхээр ажиллаж байна. Ansible нь анхан шатны тохиргоонд сайн хүрээ, Хүүхэлдэй нь платформ дээр шууд практик ажиллагаа шаарддаг тул эхний тохиргоонд тааруухан байдаг ба Puppet нь тохиргооны нэгдлийг хангадаг. Энэ нь платформ нь өөрийгөө хамгийн сүүлийн үеийн байдалд байлгадаг гэсэн үг бөгөөд шинэчилсэн машиныг шинэчилж байхын тулд та үүн дээр тоглуулах номыг тодорхой давтамжтайгаар байнга ажиллуулах хэрэгтэй. Энэ бол ялгаа юм.
Та хэрхэн нийцтэй байдлыг хадгалах вэ? Танд Ansible болон Puppet хоёрын тохиргоо байдаг уу?
Энэ бол бидний хамгийн том өвдөлт, бид гараараа нийцтэй байдлыг хадгалж, энэ бүхнээс одоо хаа нэгтээ хэрхэн шилжих талаар бодож байна. Хүүхэлдэй нь багцуудыг гаргаж, тэнд зарим холбоосыг хадгалдаг бөгөөд жишээлбэл, Ansible нь кодыг гаргаж, хамгийн сүүлийн үеийн програмын тохиргоог тохируулдаг.
Энэхүү танилцуулга нь Ruby-ийн өөр өөр хувилбаруудын тухай байв. Ямар шийдэл вэ?
Бид нэг газар ийм зүйлтэй тулгарсан бөгөөд бид үүнийг үргэлж толгойдоо байлгах ёстой. Бид зүгээр л Ruby дээр ажиллаж байсан программуудтай таарахгүй хэсгийг унтрааж, тусад нь хадгалсан.
Энэ жилийн чуулган 7-р сарын 11-нд Технополист болно. Бид XNUMX-р сарын XNUMX хүртэл тайлангийн материалыг хүлээн авч байна. Хэрэв та ярихыг хүсвэл бидэнтэй холбоо барина уу.
Оролцогчдын бүртгэл нээлттэй байна, бидэнтэй нэгдээрэй!
Эх сурвалж: www.habr.com