Энэ нийтлэлд би бүтээгдэхүүнийхээ үйл ажиллагааг хөгжүүлэх санааг сонгох туршлагаасаа хуваалцаж, хөгжлийн үндсэн векторуудыг хэрхэн хадгалахыг танд хэлэх болно.
Бид тооцооны автоматжуулсан систем (ACS) - тооцоог боловсруулж байна. Хугацаа
Манай бүтээгдэхүүний ашиглалтын хугацаа 14 жил. Энэ хугацаанд систем нь үйлдвэрлэлийн үнэлгээний анхны хувилбаруудаас бие биенээ нөхөх 18 бүтээгдэхүүнээс бүрдсэн модульчлагдсан цогцолбор руу шилжсэн. Хөтөлбөрийн урт наслалтын хамгийн чухал талуудын нэг бол тасралтгүй хөгжүүлэлт юм. Мөн хөгжилд санаа хэрэгтэй.
Идеи
Эх сурвалжууд
5 эх сурвалж байдаг:
- Корпорацийн мэдээллийн системийг хөгжүүлэгчийн гол найз нь үйлчлүүлэгч. Үйлчлүүлэгч гэдэг нь шийдвэр гаргагчид, төслийн ивээн тэтгэгчид, үйл явцын эзэд, гүйцэтгэгчид, дотоод мэдээллийн технологийн мэргэжилтнүүд, энгийн хэрэглэгчид, янз бүрийн зэрэгтэй сонирхолтой олон тооны хүмүүсийн хамтын дүр төрх юм. Үйлчлүүлэгчийн төлөөлөгч бүр санаа нийлүүлэгч байх нь бидний хувьд чухал юм. Хамгийн муу тохиолдолд бид систем дэх асуудлын талаар зөвхөн сөрөг хариуг авдаг. Сайндаа л үйлчлүүлэгчийн тал дээр үйлчлүүлэгчийн хэрэгцээ шаардлагын талаар бүтэцлэгдсэн мэдээллээр хангаж, сайжруулах санааны байнгын эх сурвалж болдог хүн байдаг.
- Манай худалдагч, дансны менежерүүд сайжруулах санааны хоёр дахь чухал эх сурвалж юм. Тэд салбарын төлөөлөгчидтэй маш идэвхтэй харилцаж, боломжит үйлчлүүлэгчдээс тооцооны функцтэй холбоотой хүсэлтийг хүлээн авдаг. Худалдаачид болон дансууд өөрсдийн үйл ажиллагааны бүх томоохон өөрчлөлтүүд болон өрсөлдөгчдийн програм хангамжийн хамгийн сүүлийн үеийн шинэчлэлтүүдийг мэдэж байх ёстой, өөр өөр шийдлүүдийн давуу болон сул талуудыг зөвтгөх чадвартай байх ёстой. Манай эдгээр ажилчид төлбөр тооцооны зарим функцууд де факто стандарт болж, үүнгүйгээр програм хангамжийг бүрэн гүйцэд гэж үзэх боломжгүй гэдгийг хамгийн түрүүнд мэдэрдэг.
- Бүтээгдэхүүний эзэн бол манай шилдэг менежерүүдийн нэг эсвэл маш туршлагатай төслийн менежер юм. Компанийн стратегийн зорилгыг санаж, түүнд нийцүүлэн бүтээгдэхүүн хөгжүүлэх төлөвлөгөөг тохируулдаг.
- Архитектор, сонгосон / ашигласан технологийн шийдлүүдийн боломж, хязгаарлалт, бүтээгдэхүүний хөгжилд үзүүлэх нөлөөллийг ойлгодог хүн.
Хөгжүүлэлт, туршилтын багууд. Бүтээгдэхүүн боловсруулахад шууд оролцдог хүмүүс.
Хитүүдийн ангилал
Бид эх сурвалжаас түүхий мэдээллийг хүлээн авдаг - захидал, тасалбар, аман хүсэлт. Бүгд
Давж заалдах гомдлыг дараахь байдлаар ангилдаг.
- Зөвлөгөө өгөх "Үүнийг яаж хийх вэ?", "Энэ нь яаж ажилладаг вэ?", "Яагаад ажиллахгүй байна вэ?", "Би ойлгохгүй байна ..." гэсэн утгатай. Энэ төрлийн дуудлага нь 1-р түвшний дэмжлэгийн шугам руу очдог. Зөвлөгөөг бусад төрлийн давж заалдах өргөдөлд сургах боломжтой.
- Үйл явдал "Ажиллахгүй" ба "Алдаа" гэсэн утгатай. 2 ба 3 тулгуур шугамаар зохицуулагдана. Хэрэв нөхөөсийг хурдан засч, суллах шаардлагатай бол түүнийг дэмжлэгээс шууд хөгжүүлэлт рүү шилжүүлж болно. Үүнийг өөрчлөх хүсэлт болгон дахин ангилж, хоцрогдол руу илгээх боломжтой.
- Өөрчлөлт, хөгжлийн хүсэлт. Дэмжлэгийн шугамыг алгасаж, бүтээгдэхүүний нөөцөд ороорой. Гэхдээ тэдний хувьд тусдаа боловсруулах журам байдаг.
Хитүүдийн тухай ийм статистик байдаг - гарсан даруйд хитүүдийн тоо богино хугацаанд 10-15% -иар өсдөг. Мөн манай үүлэн үйлчилгээнд олон тооны хэрэглэгчтэй шинэ үйлчлүүлэгч ирэх үед дуудлагын тасалбар ирдэг. Хүмүүс програм хангамжийн шинэ боломжуудыг ашиглаж сурч байгаа тул тэдэнд зөвлөгөө хэрэгтэй байна. Жижиг үйлчлүүлэгч ч гэсэн системд ажиллаж эхлэхдээ сард 100 гаруй цагийн зөвлөгөөг амархан шатаадаг. Тиймээс, шинэ үйлчлүүлэгчийг холбохдоо бид анхны зөвлөгөө авах цагийг үргэлж нөөцөлдөг. Ихэнхдээ бид тодорхой мэргэжилтэнг онцлон тэмдэглэдэг. Түрээсийн төлбөр нь мэдээжийн хэрэг эдгээр хөдөлмөрийн зардлыг нөхдөггүй, гэхдээ цаг хугацаа өнгөрөх тусам нөхцөл байдал жигдэрсэн. Дасан зохицох хугацаа нь дүрмээр бол 1-ээс 3 сар хүртэл үргэлжилдэг бөгөөд үүний дараа зөвлөгөө авах хэрэгцээ мэдэгдэхүйц буурдаг.
Өмнө нь бид дуудлага хадгалахдаа өөрөө бичсэн шийдлүүдийг ашигладаг байсан. Гэвч аажмаар Atlassian бүтээгдэхүүн рүү шилжсэн. Эхлээд Agile дээр ажиллахад хялбар болгохын тулд хөгжүүлэлтийг шилжүүлж, дараа нь дэмжлэг үзүүлэв. Одоо бүх чухал процессууд Jira SD-д амьдардаг бөгөөд тэд Jira-д зориулсан төрөл бүрийн залгаасууд болон Confluence-ээр хангагдсан. Өөрөө бичсэн шийдлүүд нь зөвхөн компанийн үйл ажиллагаанд чухал биш үйл явц дээр л үлдсэн. Бидний даалгаврууд одоо эцэс төгсгөлгүй, тэдгээрийг нэг системээс нөгөөд шилжихгүйгээр дэмжлэг, хөгжлийн хооронд шилжүүлэх боломжтой болсон.
Энэхүү багцаас бид бүх ажил, төлөвлөсөн болон бодит хөдөлмөрийн зардлын талаарх мэдээллийг авч, үйлчлүүлэгчдэд зориулсан тооцооны янз бүрийн хувилбаруудыг ашиглаж, дотоод хэрэгцээний баримт бичиг, үйлчлүүлэгчдэд тайлан гаргах боломжтой.
Өөрчлөлтийн хүсэлтийг боловсруулж байна
Ихэвчлэн эдгээр хүсэлтүүд нь онцлог шинж чанаруудын шаардлагын хэлбэрээр ирдэг. Манай шинжээч хүсэлтийг судалж, тодорхойлолт, дээд түвшний TOR-г гаргадаг. Тодорхойлолт болон TOR-г энэ хүсэлтийг хүлээн авахаар илгээсэн хүнд шилжүүлдэг - бид үйлчлүүлэгчтэй ижил хэлээр ярьдаг гэдэгт итгэлтэй байх ёстой.
Үйлчлүүлэгчээс бид бие биенээ зөв ойлгосон гэсэн баталгааг хүлээн авсны дараа шинжээч нь хүсэлтийг бүтээгдэхүүний нөөцөд оруулна.
Бүтээгдэхүүний онцлогийн менежмент
Хоцрогдол нь өөрчлөлт, хөгжлийн талаар хүлээн авсан хүсэлтүүдийг хуримтлуулдаг. Захирал, засвар үйлчилгээ, хөгжил, борлуулалтын дарга, системийн архитектороос бүрдсэн техникийн зөвлөл хагас жил тутамд нэг удаа хуралддаг. Хэлэлцүүлгийн хэлбэрээр зөвлөл нь хоцрогдсон өргөдлүүдэд дүн шинжилгээ хийж, эрэмбэлэх ба дараагийн хувилбарт хэрэгжүүлэх 5 хөгжүүлэх ажлыг тохиролцдог.
Үнэн хэрэгтээ техникийн зөвлөл нь өргөдөлд тусгагдсан хэрэгцээг харгалзан салбар, зах зээлийн шаардлагад хариу үйлдэл үзүүлдэг. Ач холбогдол багатай бүхэн хоцрогдолд үлдэж, хөгжилд хүрэхгүй.
Өөрчлөлт хийх хүсэлтийн ангилал ба санхүү
Хөгжил нь үнэтэй байдаг. Тиймээс, өөрчлөлтийн хүсэлтийг ажилтан биш харин үйлчлүүлэгчээс ирүүлсэн тохиолдолд бид ямар сонголттой болохыг шууд хэлэх болно.
Өөрчлөлт хийх хүсэлтийг дараах байдлаар ангилдаг: салбарын онцлогт тохирсон хэрэгцээ эсвэл аж ахуйн нэгжийн хувь хүний онцлог; их хэмжээний шинэ функц эсвэл жижиг засвар. Жижиг засварууд болон хувь хүний хүсэлтийг ямар ч саадгүйгээр боловсруулдаг. Төслийн ажлын хүрээнд тодорхой үйлчлүүлэгчийн хувийн хүсэлтийг тооцоолж, хэрэгжүүлдэг.
Хэрэв энэ нь үйлдвэрлэлийн асар их хэрэгцээ биш бөгөөд функциональ хэмжээ их байвал үндсэн функцээс гадна зарагдах шинэ тусдаа модулийг боловсруулах шийдвэр гаргаж болно. Үйлчлүүлэгчээс ийм хүсэлт ирсэн тохиолдолд бид модулийг хөгжүүлэх зардлыг нөхөж, модулийг үйлчлүүлэгчид үнэ төлбөргүй эсвэл хэсэгчилсэн төлбөртэйгээр өгч, модулийг нийтийн эзэмшлийн газарт зарах боломжтой. Ийм нөхцөлд үйлчлүүлэгч арга зүйн ачааллын нэг хэсгийг хариуцаж, үнэн хэрэгтээ модулийн туршилтын хэрэгжилтийг явуулдаг.
Хэрэв энэ нь үйлдвэрлэлийн асар том хэрэгцээ бол үндсэн бүтээгдэхүүнд шинэ функцийг оруулах шийдвэр гаргаж болно. Энэ тохиолдолд зардлыг бид бүрэн хариуцдаг бөгөөд шинэ функц нь програмын одоогийн хувилбарт гарч ирнэ.
Хуучин хэрэглэгчдэд шинэчлэлтийг хүргэж байна.
Энэ нь хэд хэдэн хэрэглэгчид ижил төстэй хэрэгцээтэй байж болох ч энэ нь олон нийтийн бүтээгдэхүүнийг татахгүй. Энэ тохиолдолд бид эдгээр хэрэглэгчдэд техникийн тодорхойлолтыг илгээж, тэдний хооронд хөгжүүлэлтийн зардлыг хуваалцахыг санал болгож болно. Эцэст нь хүн бүр ялах болно: үйлчлүүлэгчид энэ функцийг хямд зардлаар хэрэгжүүлдэг, бид бүтээгдэхүүнээ баяжуулдаг, хэсэг хугацааны дараа зах зээлийн бусад оролцогчид өөрсдийн ашиглах функцийг авах боломжтой.
DevOps
Хөгжил нь жилд хоёр томоохон хувилбар бэлтгэдэг. Хувилбар бүрт техникийн зөвлөлөөс хүлээн авсан 5 даалгаврыг хэрэгжүүлэхэд цаг хугацаа зарцуулдаг. Тиймээс бараа эргэлтийн ард бид бүтээгдэхүүний хөгжлийг хэзээ ч мартдаггүй.
Хувилбар бүр нь зохих тест, баримт бичгийн багцыг дамждаг. Цаашилбал, энэхүү хувилбарыг харгалзах хэрэглэгчийн туршилтын орчинд суулгасан бөгөөд тэр нь эргээд бүх зүйлийг сайтар шалгаж, үүний дараа л хувилбарыг үйлдвэрлэлд шилжүүлдэг.
Хувилбарын системээс гадна алдааг хурдан засах формат байдаг бөгөөд ингэснээр үйлчлүүлэгчид зургаан сарын турш алдаатай амьдрахгүй байх болно. Энэхүү завсрын формат нь танд нэн тэргүүний зорилтуудын тохиолдлуудад хурдан хариу арга хэмжээ авах, заасан SLA-ийг биелүүлэх боломжийг олгоно.
Дээр дурдсан бүх зүйл нь үндсэндээ корпорацийн салбар болон газар дээрх шийдлүүдийн хувьд үнэн юм. SMB сегментэд чиглэсэн үүлэн үйлчилгээний хувьд үйлчлүүлэгчдэд бүтээгдэхүүн боловсруулахад оролцох тийм өргөн боломж байдаггүй. SMB-ийн түрээсийн хэлбэр нь үүнийг санал болгодоггүй. Корпорацын талаас тодорхой шаардлагын хэлбэрээр өөрчлөлт оруулах хүсэлтийн оронд зөвхөн үйлчилгээний талаархи ердийн санал хүсэлт, хүсэлт байдаг. Бид сонсохыг хичээдэг ч бүтээгдэхүүн нь асар том бөгөөд нэг үйлчлүүлэгчийн хуучин түүхэн системээсээ танил зүйлийг авчрах хүсэл нь бүхэлдээ системийн хөгжлийн стратегитай зөрчилдөж магадгүй юм.
Эх сурвалж: www.habr.com