ພວກເຮົາຊອກຫາຄວາມຜິດປົກກະຕິແລະຄາດຄະເນຄວາມລົ້ມເຫລວໂດຍໃຊ້ເຄືອຂ່າຍ neural

ການພັດທະນາອຸດສາຫະກໍາຂອງລະບົບຊອບແວຮຽກຮ້ອງໃຫ້ມີຄວາມສົນໃຈຢ່າງຫຼວງຫຼາຍຕໍ່ຄວາມທົນທານຕໍ່ຄວາມຜິດຂອງຜະລິດຕະພັນສຸດທ້າຍ, ເຊັ່ນດຽວກັນກັບການຕອບສະຫນອງຢ່າງໄວວາຕໍ່ຄວາມລົ້ມເຫລວແລະຄວາມລົ້ມເຫລວຖ້າພວກມັນເກີດຂື້ນ. ການຕິດຕາມ, ແນ່ນອນ, ຊ່ວຍໃຫ້ການຕອບສະຫນອງຕໍ່ຄວາມລົ້ມເຫລວແລະຄວາມລົ້ມເຫລວຫຼາຍປະສິດທິຜົນແລະໄວ, ແຕ່ບໍ່ພຽງພໍ. ຫນ້າທໍາອິດ, ມັນເປັນການຍາກຫຼາຍທີ່ຈະຕິດຕາມຈໍານວນເຄື່ອງແມ່ຂ່າຍຫຼາຍ - ຈໍານວນຄົນທີ່ຕ້ອງການ. ອັນທີສອງ, ທ່ານຈໍາເປັນຕ້ອງມີຄວາມເຂົ້າໃຈດີກ່ຽວກັບວິທີການເຮັດວຽກຂອງແອັບພລິເຄຊັນເພື່ອຄາດຄະເນສະຖານະຂອງມັນ. ດັ່ງນັ້ນ, ພວກເຮົາຕ້ອງການຫຼາຍໆຄົນທີ່ມີຄວາມເຂົ້າໃຈດີກ່ຽວກັບລະບົບທີ່ພວກເຮົາກໍາລັງພັດທະນາ, ການປະຕິບັດແລະຄຸນສົມບັດຂອງພວກເຂົາ. ໃຫ້ສົມມຸດວ່າເຖິງແມ່ນວ່າເຈົ້າຈະພົບເຫັນຄົນເຕັມໃຈທີ່ຈະເຮັດສິ່ງນີ້, ມັນຍັງໃຊ້ເວລາຫຼາຍໃນການຝຶກອົບຮົມໃຫ້ເຂົາເຈົ້າ.

ຈະເຮັດແນວໃດ? ນີ້ແມ່ນບ່ອນທີ່ປັນຍາປະດິດມາຊ່ວຍເຫຼືອຂອງພວກເຮົາ. ບົດຄວາມຈະເວົ້າກ່ຽວກັບ ການ​ບໍາ​ລຸງ​ຮັກ​ສາ​ການ​ຄາດ​ຄະ​ເນ​ (ການ​ດູ​ແລ​ການ​ຄາດ​ຄະ​ເນ​)​. ວິທີການນີ້ແມ່ນໄດ້ຮັບຄວາມນິຍົມຢ່າງຈິງຈັງ. ບົດຄວາມຈໍານວນຫລາຍໄດ້ຖືກຂຽນ, ລວມທັງກ່ຽວກັບHabre. ບໍລິສັດຂະຫນາດໃຫຍ່ໃຊ້ວິທີການນີ້ຢ່າງເຕັມທີ່ເພື່ອຮັກສາການປະຕິບັດຂອງເຄື່ອງແມ່ຂ່າຍຂອງພວກເຂົາ. ຫຼັງຈາກການສຶກສາບົດຄວາມຈໍານວນຫລາຍ, ພວກເຮົາໄດ້ຕັດສິນໃຈທົດລອງວິທີການນີ້. ມັນມາຈາກຫຍັງ?

ການນໍາສະເຫນີ

ລະ​ບົບ​ຊອບ​ແວ​ທີ່​ພັດ​ທະ​ນາ​ໄວ​ຫຼື​ຫຼັງ​ຈາກ​ນັ້ນ​ເຂົ້າ​ໄປ​ໃນ​ການ​ດໍາ​ເນີນ​ງານ​. ມັນເປັນສິ່ງສໍາຄັນສໍາລັບຜູ້ໃຊ້ທີ່ລະບົບເຮັດວຽກໂດຍບໍ່ມີການລົ້ມເຫລວ. ຖ້າເຫດການສຸກເສີນເກີດຂື້ນ, ມັນຄວນຈະໄດ້ຮັບການແກ້ໄຂດ້ວຍການຊັກຊ້າຫນ້ອຍທີ່ສຸດ.

ເພື່ອຄວາມງ່າຍຂອງການສະຫນັບສະຫນູນດ້ານວິຊາການຂອງລະບົບຊອບແວ, ໂດຍສະເພາະຖ້າມີເຄື່ອງແມ່ຂ່າຍຫຼາຍ, ໂປລແກລມຕິດຕາມກວດກາມັກຈະຖືກນໍາໃຊ້ທີ່ເອົາ metrics ຈາກລະບົບຊອບແວທີ່ເຮັດວຽກ, ເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະວິນິດໄສສະພາບຂອງມັນແລະຊ່ວຍກໍານົດສິ່ງທີ່ເຮັດໃຫ້ເກີດຄວາມລົ້ມເຫຼວ. ຂະບວນການນີ້ເອີ້ນວ່າການກວດສອບລະບົບຊອບແວ.

ຮູບ 1. ການໂຕ້ຕອບການຕິດຕາມ Grafana

Metrics ແມ່ນຕົວຊີ້ບອກຕ່າງໆຂອງລະບົບຊອບແວ, ສະພາບແວດລ້ອມການປະຕິບັດຂອງມັນ, ຫຼືຄອມພິວເຕີທາງດ້ານຮ່າງກາຍທີ່ລະບົບກໍາລັງເຮັດວຽກກັບເວລາຂອງເວລາທີ່ໄດ້ຮັບ metrics. ໃນການວິເຄາະສະຖິດ, ຕົວຊີ້ວັດເຫຼົ່ານີ້ເອີ້ນວ່າຊຸດເວລາ. ເພື່ອຕິດຕາມສະຖານະຂອງລະບົບຊອບແວ, metrics ຈະຖືກສະແດງຢູ່ໃນຮູບແບບຂອງກາຟ: ເວລາແມ່ນຢູ່ໃນແກນ X, ແລະຄ່າແມ່ນຢູ່ຕາມແກນ Y (ຮູບ 1). ຫຼາຍພັນ metrics ສາມາດເອົາມາຈາກລະບົບຊອບແວທີ່ເຮັດວຽກ (ຈາກແຕ່ລະ node). ພວກມັນປະກອບເປັນຊ່ອງຂອງ metrics (ຊຸດເວລາຫຼາຍມິຕິ).

ເນື່ອງຈາກການວັດແທກຈໍານວນຫຼວງຫຼາຍຖືກເກັບກໍາສໍາລັບລະບົບຊອບແວທີ່ສັບສົນ, ການຕິດຕາມຄູ່ມືກາຍເປັນວຽກທີ່ຍາກ. ເພື່ອຫຼຸດຜ່ອນຈໍານວນຂໍ້ມູນທີ່ວິເຄາະໂດຍຜູ້ບໍລິຫານ, ເຄື່ອງມືຕິດຕາມມີເຄື່ອງມືເພື່ອກໍານົດບັນຫາທີ່ເປັນໄປໄດ້ໂດຍອັດຕະໂນມັດ. ຕົວຢ່າງເຊັ່ນ, ທ່ານສາມາດຕັ້ງຄ່າ trigger ທີ່ຈະໄຟໃນເວລາທີ່ພື້ນທີ່ດິດຟຣີຫຼຸດລົງຕໍ່າກວ່າເກນທີ່ກໍານົດໄວ້. ນອກນັ້ນທ່ານຍັງສາມາດວິນິດໄສການປິດເຄື່ອງແມ່ຂ່າຍອັດຕະໂນມັດຫຼືຄວາມຊ້າລົງທີ່ສໍາຄັນໃນຄວາມໄວການບໍລິການ. ໃນທາງປະຕິບັດ, ເຄື່ອງມືຕິດຕາມກວດກາເຮັດວຽກໄດ້ດີໃນການກວດສອບຄວາມລົ້ມເຫລວທີ່ເກີດຂື້ນແລ້ວຫຼືກໍານົດອາການງ່າຍໆຂອງຄວາມລົ້ມເຫລວໃນອະນາຄົດ, ແຕ່ໂດຍທົ່ວໄປແລ້ວ, ການຄາດຄະເນຄວາມລົ້ມເຫຼວທີ່ເປັນໄປໄດ້ຍັງຄົງເປັນຫມາກແຫ້ງເປືອກແຂງທີ່ຈະແຕກສໍາລັບພວກເຂົາ. ການຄາດຄະເນໂດຍຜ່ານການວິເຄາະຄູ່ມືຂອງ metrics ຮຽກຮ້ອງໃຫ້ມີການມີສ່ວນຮ່ວມຂອງຜູ້ຊ່ຽວຊານທີ່ມີຄຸນວຸດທິ. ມັນແມ່ນຜົນຜະລິດຕ່ໍາ. ຄວາມລົ້ມເຫຼວທີ່ເປັນໄປໄດ້ສ່ວນໃຫຍ່ອາດຈະບໍ່ມີໃຜສັງເກດເຫັນ.

ບໍ່ດົນມານີ້, ອັນທີ່ເອີ້ນວ່າການຮັກສາການຄາດເດົາຂອງລະບົບຊອບແວໄດ້ກາຍເປັນທີ່ນິຍົມຫລາຍຂຶ້ນໃນບັນດາບໍລິສັດພັດທະນາຊອບແວ IT ຂະຫນາດໃຫຍ່. ໂດຍເນື້ອແທ້ແລ້ວຂອງວິທີການນີ້ແມ່ນເພື່ອຊອກຫາບັນຫາທີ່ນໍາໄປສູ່ການເຊື່ອມໂຊມຂອງລະບົບໃນໄລຍະຕົ້ນ, ກ່ອນທີ່ມັນຈະລົ້ມເຫລວ, ການນໍາໃຊ້ປັນຍາປະດິດ. ວິທີການນີ້ບໍ່ໄດ້ຍົກເວັ້ນຢ່າງສົມບູນຂອງການຕິດຕາມລະບົບຄູ່ມື. ມັນ​ເປັນ​ການ​ຊ່ວຍ​ໃຫ້​ຂະ​ບວນ​ການ​ຕິດ​ຕາມ​ທັງ​ຫມົດ​.

ເຄື່ອງມືຕົ້ນຕໍໃນການປະຕິບັດການບໍາລຸງຮັກສາການຄາດເດົາແມ່ນວຽກງານຂອງການຊອກຫາຄວາມຜິດປົກກະຕິໃນຊຸດເວລາ, ນັບຕັ້ງແຕ່ ເມື່ອມີຄວາມຜິດປົກກະຕິເກີດຂຶ້ນ ໃນຂໍ້ມູນມີຄວາມເປັນໄປໄດ້ສູງວ່າຫຼັງຈາກເວລາໃດຫນຶ່ງ ຈະ​ມີ​ຄວາມ​ລົ້ມ​ເຫຼວ​ຫຼື​ຄວາມ​ລົ້ມ​ເຫຼວ​. ຄວາມຜິດປົກກະຕິແມ່ນຄວາມເສື່ອມເສີຍບາງຢ່າງໃນການປະຕິບັດຂອງລະບົບຊອບແວ, ເຊັ່ນ: ການກໍານົດການເຊື່ອມໂຊມຂອງຄວາມໄວການປະຕິບັດຂອງຄໍາຮ້ອງຂໍປະເພດຫນຶ່ງຫຼືການຫຼຸດລົງຂອງຈໍານວນຄໍາຮ້ອງຂໍການບໍລິການໂດຍສະເລ່ຍໃນລະດັບຄົງທີ່ຂອງກອງປະຊຸມລູກຄ້າ.

ວຽກງານຂອງການຄົ້ນຫາຄວາມຜິດປົກກະຕິສໍາລັບລະບົບຊອບແວມີຄວາມສະເພາະຂອງຕົນເອງ. ໃນທາງທິດສະດີ, ສໍາລັບແຕ່ລະລະບົບຊອບແວ, ມັນຈໍາເປັນຕ້ອງໄດ້ພັດທະນາຫຼືປັບປຸງວິທີການທີ່ມີຢູ່ແລ້ວ, ເພາະວ່າການຄົ້ນຫາຄວາມຜິດປົກກະຕິແມ່ນຂຶ້ນກັບຂໍ້ມູນທີ່ຖືກປະຕິບັດ, ແລະຂໍ້ມູນຂອງລະບົບຊອບແວແຕກຕ່າງກັນຢ່າງຫຼວງຫຼາຍຂຶ້ນກັບເຄື່ອງມືໃນການປະຕິບັດລະບົບ. , ລົງໄປຫາຄອມພິວເຕີທີ່ມັນກໍາລັງແລ່ນຢູ່ໃນ.

ວິທີການຄົ້ນຫາຄວາມຜິດປົກກະຕິໃນເວລາທີ່ຄາດຄະເນຄວາມລົ້ມເຫຼວຂອງລະບົບຊອບແວ

ຫນ້າທໍາອິດຂອງການທັງຫມົດ, ມັນເປັນມູນຄ່າທີ່ເວົ້າວ່າຄວາມຄິດຂອງການຄາດຄະເນຄວາມລົ້ມເຫລວໄດ້ຖືກດົນໃຈຈາກບົດຄວາມ "ການຮຽນຮູ້ເຄື່ອງຈັກໃນການຕິດຕາມ IT". ເພື່ອທົດສອບປະສິດທິພາບຂອງວິທີການທີ່ມີການຄົ້ນຫາອັດຕະໂນມັດສໍາລັບຄວາມຜິດປົກກະຕິ, ລະບົບຊອບແວ Web-Consolidation ໄດ້ຖືກເລືອກ, ເຊິ່ງເປັນຫນຶ່ງໃນໂຄງການຂອງບໍລິສັດ NPO Krista. ກ່ອນຫນ້ານີ້, ການຕິດຕາມຄູ່ມືໄດ້ຖືກປະຕິບັດສໍາລັບມັນໂດຍອີງໃສ່ metrics ທີ່ໄດ້ຮັບ. ເນື່ອງຈາກວ່າລະບົບແມ່ນຂ້ອນຂ້າງສັບສົນ, ຕົວຊີ້ວັດຈໍານວນຫລາຍໄດ້ຖືກປະຕິບັດສໍາລັບມັນ: ຕົວຊີ້ວັດ JVM (ການເກັບຂີ້ເຫຍື້ອ), ຕົວຊີ້ວັດຂອງ OS ທີ່ລະຫັດຖືກປະຕິບັດ (ຫນ່ວຍຄວາມຈໍາ virtual, % OS CPU load), ຕົວຊີ້ວັດເຄືອຂ່າຍ (ການໂຫຼດເຄືອຂ່າຍ. ), ເຊີບເວີເອງ (ການໂຫຼດ CPU , ຫນ່ວຍຄວາມຈໍາ), ຕົວຊີ້ວັດ wildfly ແລະຕົວຊີ້ວັດຂອງແອັບພລິເຄຊັນສໍາລັບລະບົບຍ່ອຍທີ່ສໍາຄັນທັງຫມົດ.

metrics ທັງຫມົດແມ່ນເອົາມາຈາກລະບົບໂດຍໃຊ້ graphite. ໃນເບື້ອງຕົ້ນ, ຖານຂໍ້ມູນ whisper ໄດ້ຖືກນໍາໃຊ້ເປັນການແກ້ໄຂມາດຕະຖານສໍາລັບ grafana, ແຕ່ຍ້ອນວ່າຖານລູກຄ້າເພີ່ມຂຶ້ນ, graphite ບໍ່ສາມາດຮັບມືກັບຄວາມສາມາດຂອງລະບົບຍ່ອຍຂອງ DC disk. ຫຼັງຈາກນີ້, ມັນໄດ້ຖືກຕັດສິນໃຈຊອກຫາວິທີແກ້ໄຂທີ່ມີປະສິດທິພາບຫຼາຍຂຶ້ນ. ທາງ​ເລືອກ​ໄດ້​ຖືກ​ເຮັດ​ໃຫ້​ເຫັນ​ດີ graphite+ clickhouse, ເຊິ່ງເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະຫຼຸດຜ່ອນການໂຫຼດໃນລະບົບຍ່ອຍຂອງແຜ່ນໂດຍຄໍາສັ່ງຂອງຂະຫນາດແລະຫຼຸດຜ່ອນພື້ນທີ່ດິດທີ່ຄອບຄອງໂດຍຫ້າຫາຫົກເທົ່າ. ຂ້າງລຸ່ມນີ້ແມ່ນແຜນວາດຂອງກົນໄກການເກັບຄ່າວັດແທກໂດຍໃຊ້ graphite+clickhouse (ຮູບ 2).

ຮູບທີ 2. ໂຄງຮ່າງການເກັບກຳຕົວວັດແທກ

ແຜນວາດແມ່ນເອົາມາຈາກເອກະສານພາຍໃນ. ມັນສະແດງໃຫ້ເຫັນການສື່ສານລະຫວ່າງ grafana (UI ການຕິດຕາມທີ່ພວກເຮົາໃຊ້) ແລະ graphite. ການຖອນ metrics ອອກຈາກແອັບພລິເຄຊັນແມ່ນເຮັດໂດຍຊອບແວແຍກຕ່າງຫາກ - jmxtrans. ລາວເຮັດໃຫ້ພວກເຂົາຢູ່ໃນ graphite.
ລະບົບ Web Consolidation ມີຫຼາຍລັກສະນະທີ່ສ້າງບັນຫາສໍາລັບການຄາດຄະເນຄວາມລົ້ມເຫລວ:

1. ແນວໂນ້ມມັກຈະມີການປ່ຽນແປງ. ຮຸ່ນຕ່າງໆແມ່ນມີຢູ່ໃນລະບົບຊອບແວນີ້. ພວກເຂົາແຕ່ລະຄົນນໍາເອົາການປ່ຽນແປງໃນສ່ວນຂອງຊອບແວຂອງລະບົບ. ຕາມນັ້ນແລ້ວ, ໃນລັກສະນະນີ້, ນັກພັດທະນາໂດຍກົງມີອິດທິພົນຕໍ່ metrics ຂອງລະບົບໃດຫນຶ່ງແລະສາມາດເຮັດໃຫ້ເກີດການປ່ຽນແປງແນວໂນ້ມ;
2. ລັກສະນະການປະຕິບັດ, ເຊັ່ນດຽວກັນກັບຈຸດປະສົງທີ່ລູກຄ້າໃຊ້ລະບົບນີ້, ມັກຈະເຮັດໃຫ້ເກີດຄວາມຜິດປົກກະຕິໂດຍບໍ່ມີການທໍາລາຍກ່ອນຫນ້ານີ້;
3. ເປີເຊັນຂອງຄວາມຜິດປົກກະຕິທີ່ກ່ຽວຂ້ອງກັບຊຸດຂໍ້ມູນທັງຫມົດແມ່ນນ້ອຍ (< 5%);
4. ອາດຈະມີຊ່ອງຫວ່າງໃນການຮັບຕົວຊີ້ວັດຈາກລະບົບ. ໃນບາງໄລຍະເວລາສັ້ນໆ, ລະບົບການຕິດຕາມບໍ່ສາມາດໄດ້ຮັບຕົວຊີ້ວັດ. ຕົວຢ່າງ, ຖ້າເຄື່ອງແມ່ຂ່າຍແມ່ນ overloaded. ນີ້ແມ່ນສິ່ງສໍາຄັນສໍາລັບການຝຶກອົບຮົມເຄືອຂ່າຍ neural. ມີຄວາມຕ້ອງການທີ່ຈະຕື່ມຂໍ້ມູນໃສ່ໃນຊ່ອງຫວ່າງສັງເຄາະ;
5. ກໍລະນີທີ່ມີຄວາມຜິດປົກກະຕິມັກຈະມີຄວາມກ່ຽວຂ້ອງພຽງແຕ່ວັນທີ/ເດືອນ/ເວລາສະເພາະ (ຕາມລະດູການ). ລະບົບນີ້ມີກົດລະບຽບທີ່ຊັດເຈນສໍາລັບການນໍາໃຊ້ຂອງມັນໂດຍຜູ້ໃຊ້. ຕາມ​ນັ້ນ​ແລ້ວ, metrics ແມ່ນ​ກ່ຽວ​ຂ້ອງ​ພຽງ​ແຕ່​ສໍາ​ລັບ​ການ​ໃຊ້​ເວ​ລາ​ສະ​ເພາະ​ໃດ​ຫນຶ່ງ. ລະບົບບໍ່ສາມາດຖືກນໍາໃຊ້ຢ່າງຕໍ່ເນື່ອງ, ແຕ່ວ່າພຽງແຕ່ໃນບາງເດືອນ: ເລືອກໂດຍອີງຕາມປີ. ສະຖານະການເກີດຂື້ນໃນເວລາທີ່ພຶດຕິກໍາດຽວກັນຂອງ metrics ໃນກໍລະນີຫນຶ່ງສາມາດນໍາໄປສູ່ຄວາມລົ້ມເຫຼວຂອງລະບົບຊອບແວ, ແຕ່ບໍ່ແມ່ນໃນກໍລະນີອື່ນ.
   ເພື່ອເລີ່ມຕົ້ນດ້ວຍ, ວິທີການກວດຫາຄວາມຜິດປົກກະຕິໃນການຕິດຕາມຂໍ້ມູນຂອງລະບົບຊອບແວໄດ້ຖືກວິເຄາະ. ໃນບົດຄວາມກ່ຽວກັບຫົວຂໍ້ນີ້, ເມື່ອອັດຕາສ່ວນຂອງຜິດປົກກະຕິແມ່ນຫນ້ອຍທີ່ກ່ຽວຂ້ອງກັບສ່ວນທີ່ເຫຼືອຂອງຊຸດຂໍ້ມູນ, ມັນມັກຈະຖືກສະເຫນີໃຫ້ໃຊ້ເຄືອຂ່າຍ neural.

ເຫດຜົນພື້ນຖານສໍາລັບການຄົ້ນຫາຄວາມຜິດປົກກະຕິໂດຍໃຊ້ຂໍ້ມູນເຄືອຂ່າຍ neural ແມ່ນສະແດງຢູ່ໃນຮູບ 3:

ຮູບທີ 3. ການຊອກຫາຄວາມຜິດປົກກະຕິໂດຍໃຊ້ເຄືອຂ່າຍ neural

ອີງຕາມຜົນຂອງການຄາດຄະເນຫຼືການຟື້ນຟູຂອງປ່ອງຢ້ຽມຂອງການໄຫຼຂອງ metrics ໃນປະຈຸບັນ, ການ deviation ຈາກທີ່ໄດ້ຮັບຈາກລະບົບຊອບແວທີ່ແລ່ນແມ່ນຄິດໄລ່. ຖ້າມີຄວາມແຕກຕ່າງກັນຢ່າງຫຼວງຫຼາຍລະຫວ່າງ metrics ທີ່ໄດ້ຮັບຈາກລະບົບຊອບແວແລະເຄືອຂ່າຍ neural, ພວກເຮົາສາມາດສະຫຼຸບໄດ້ວ່າສ່ວນຂໍ້ມູນໃນປະຈຸບັນແມ່ນຜິດປົກກະຕິ. ຊຸດຂອງບັນຫາຕໍ່ໄປນີ້ເກີດຂື້ນສໍາລັບການນໍາໃຊ້ເຄືອຂ່າຍ neural:

1. ເພື່ອເຮັດວຽກຢ່າງຖືກຕ້ອງໃນໂຫມດການຖ່າຍທອດ, ຂໍ້ມູນສໍາລັບການຝຶກອົບຮົມແບບເຄືອຂ່າຍ neural ຕ້ອງປະກອບມີຂໍ້ມູນ "ປົກກະຕິ" ເທົ່ານັ້ນ;
2. ມັນຈໍາເປັນຕ້ອງມີຮູບແບບທີ່ທັນສະ ໄໝ ສໍາລັບການກວດພົບທີ່ຖືກຕ້ອງ. ການປ່ຽນແປງທ່າອ່ຽງແລະລະດູການໃນ metrics ສາມາດເຮັດໃຫ້ເກີດຜົນບວກທີ່ບໍ່ຖືກຕ້ອງຈໍານວນຫລາຍໃນຕົວແບບ. ເພື່ອປັບປຸງມັນ, ມັນຈໍາເປັນຕ້ອງກໍານົດຢ່າງຊັດເຈນເວລາທີ່ຮູບແບບລ້າສະໄຫມ. ຖ້າທ່ານປັບປຸງແບບຈໍາລອງໃນພາຍຫລັງຫຼືກ່ອນຫນ້ານັ້ນ, ສ່ວນຫຼາຍອາດຈະ, ຈໍານວນຜົນບວກທີ່ບໍ່ຖືກຕ້ອງຈະປະຕິບັດຕາມ.
   ພວກເຮົາຍັງຕ້ອງບໍ່ລືມກ່ຽວກັບການຊອກຫາແລະປ້ອງກັນການປະກົດຕົວເລື້ອຍໆຂອງຜົນບວກທີ່ບໍ່ຖືກຕ້ອງ. ມັນຄາດວ່າພວກມັນມັກຈະເກີດຂື້ນໃນສະຖານະການສຸກເສີນ. ຢ່າງໃດກໍ່ຕາມ, ພວກມັນອາດຈະເປັນຜົນມາຈາກຄວາມຜິດພາດຂອງເຄືອຂ່າຍ neural ເນື່ອງຈາກການຝຶກອົບຮົມບໍ່ພຽງພໍ. ມັນເປັນສິ່ງຈໍາເປັນເພື່ອຫຼຸດຜ່ອນຈໍານວນຜົນບວກທີ່ບໍ່ຖືກຕ້ອງຂອງຕົວແບບ. ຖ້າບໍ່ດັ່ງນັ້ນ, ການຄາດຄະເນທີ່ບໍ່ຖືກຕ້ອງຈະເສຍເວລາຫຼາຍຂອງຜູ້ບໍລິຫານທີ່ມີຈຸດປະສົງໃນການກວດສອບລະບົບ. ບໍ່ດົນຫຼືຫຼັງຈາກນັ້ນຜູ້ເບິ່ງແຍງລະບົບພຽງແຕ່ຈະຢຸດເຊົາການຕອບສະຫນອງຕໍ່ລະບົບການຕິດຕາມ "ວິຕົກກັງວົນ".

ເຄືອຂ່າຍ neural ເກີດຂຶ້ນຊ້ຳ

ເພື່ອກວດຫາຄວາມຜິດປົກກະຕິໃນຊຸດເວລາ, ທ່ານສາມາດນໍາໃຊ້ ເຄືອຂ່າຍ neural recurrent ກັບຫນ່ວຍຄວາມຈໍາ LSTM. ບັນຫາພຽງແຕ່ວ່າມັນສາມາດຖືກນໍາໃຊ້ສໍາລັບຊຸດເວລາຄາດຄະເນເທົ່ານັ້ນ. ໃນກໍລະນີຂອງພວກເຮົາ, ບໍ່ແມ່ນການວັດແທກທັງຫມົດແມ່ນສາມາດຄາດເດົາໄດ້. ຄວາມພະຍາຍາມທີ່ຈະນໍາໃຊ້ RNN LSTM ກັບຊຸດເວລາແມ່ນສະແດງຢູ່ໃນຮູບ 4.

ຮູບທີ 4. ຕົວຢ່າງຂອງເຄືອຂ່າຍ neural recurrent ກັບຈຸລັງຫນ່ວຍຄວາມຈໍາ LSTM

ດັ່ງທີ່ເຫັນໄດ້ຈາກຮູບທີ 4, RNN LSTM ສາມາດຮັບມືກັບການຄົ້ນຫາຄວາມຜິດປົກກະຕິໃນໄລຍະເວລານີ້. ບ່ອນທີ່ຜົນໄດ້ຮັບມີຄວາມຜິດພາດໃນການຄາດຄະເນສູງ (ຄວາມຜິດພາດຫມາຍຄວາມວ່າ), ຄວາມຜິດປົກກະຕິໃນຕົວຊີ້ວັດໄດ້ເກີດຂຶ້ນຈິງ. ການນໍາໃຊ້ RNN LSTM ດຽວຈະບໍ່ພຽງພໍຢ່າງຈະແຈ້ງ, ເນື່ອງຈາກວ່າມັນສາມາດໃຊ້ໄດ້ກັບຈໍານວນຂະຫນາດນ້ອຍຂອງ metrics. ສາມາດໃຊ້ເປັນວິທີການຊ່ວຍໃນການຄົ້ນຫາຄວາມຜິດປົກກະຕິ.

Autoencoder ສໍາລັບການຄາດຄະເນຄວາມລົ້ມເຫລວ

ຕົວເຂົ້າລະຫັດອັດຕະໂນມັດ - ເປັນເຄືອຂ່າຍ neural ທຽມ. ຊັ້ນປ້ອນຂໍ້ມູນແມ່ນຕົວເຂົ້າລະຫັດ, ຊັ້ນຜົນຜະລິດແມ່ນຕົວຖອດລະຫັດ. ຂໍ້ເສຍຂອງເຄືອຂ່າຍ neural ທັງຫມົດຂອງປະເພດນີ້ແມ່ນວ່າພວກເຂົາບໍ່ໄດ້ localize ຜິດປົກກະຕິໄດ້ດີ. ສະຖາປັດຕະຍະກຳຕົວເຂົ້າລະຫັດອັດຕະໂນມັດ synchronous ຖືກເລືອກ.

ຮູບທີ 5. ຕົວຢ່າງຂອງການປະຕິບັດການເຂົ້າລະຫັດອັດຕະໂນມັດ

Autoencoders ໄດ້ຮັບການຝຶກອົບຮົມກ່ຽວກັບຂໍ້ມູນປົກກະຕິແລະຫຼັງຈາກນັ້ນຊອກຫາສິ່ງທີ່ຜິດປົກກະຕິໃນຂໍ້ມູນທີ່ປ້ອນກັບຕົວແບບ. ພຽງແຕ່ສິ່ງທີ່ທ່ານຕ້ອງການສໍາລັບວຽກງານນີ້. ສິ່ງທີ່ຍັງເຫຼືອແມ່ນການເລືອກຕົວເຂົ້າລະຫັດອັດຕະໂນມັດທີ່ເຫມາະສົມສໍາລັບວຽກງານນີ້. ຮູບແບບສະຖາປັດຕະຍະກໍາທີ່ງ່າຍດາຍທີ່ສຸດຂອງ autoencoder ແມ່ນເຄືອຂ່າຍ neural ໄປຂ້າງຫນ້າ, ບໍ່ກັບຄືນ, ເຊິ່ງຄ້າຍຄືກັນກັບ. perceptron ຫຼາຍຊັ້ນ (multilayer perceptron, MLP), ທີ່ມີຊັ້ນປ້ອນຂໍ້ມູນ, ຊັ້ນຜົນຜະລິດ, ແລະຫນຶ່ງຫຼືຫຼາຍຊັ້ນເຊື່ອງໄວ້ເຊື່ອມຕໍ່ພວກມັນ.
ຢ່າງໃດກໍຕາມ, ຄວາມແຕກຕ່າງລະຫວ່າງ autoencoders ແລະ MLPs ແມ່ນວ່າໃນ autoencoder, ຊັ້ນຜົນຜະລິດມີຈໍານວນຂອງ nodes ດຽວກັນກັບຊັ້ນປ້ອນຂໍ້ມູນ, ແລະວ່າແທນທີ່ຈະໄດ້ຮັບການຝຶກອົບຮົມເພື່ອຄາດຄະເນມູນຄ່າເປົ້າຫມາຍ Y ທີ່ໄດ້ຮັບໂດຍການປ້ອນຂໍ້ມູນ X, autoencoder ໄດ້ຖືກຝຶກອົບຮົມ. ເພື່ອກໍ່ສ້າງ Xs ຂອງຕົນເອງ, ດັ່ງນັ້ນ, Autoencoders ແມ່ນຕົວແບບການຮຽນຮູ້ທີ່ບໍ່ໄດ້ຮັບການເບິ່ງແຍງ.

ວຽກງານຂອງ autoencoder ແມ່ນເພື່ອຊອກຫາຕົວຊີ້ວັດທີ່ໃຊ້ເວລາ r0 ... rn ທີ່ສອດຄ້ອງກັນກັບອົງປະກອບຜິດປົກກະຕິໃນ vector ວັດສະດຸປ້ອນ X. ຜົນກະທົບນີ້ແມ່ນບັນລຸໄດ້ໂດຍການຊອກຫາຄວາມຜິດພາດສອງເທົ່າ.

ຮູບທີ 6. Synchronous autoencoder

ສໍາລັບຕົວເຂົ້າລະຫັດອັດຕະໂນມັດໄດ້ຖືກເລືອກ ສະຖາປັດຕະຍະກໍາ synchronous. ຂໍ້ໄດ້ປຽບຂອງມັນ: ຄວາມສາມາດໃນການນໍາໃຊ້ຮູບແບບການປະມວນຜົນ streaming ແລະຈໍານວນຕົວກໍານົດການເຄືອຂ່າຍ neural ຂ້ອນຂ້າງຫນ້ອຍເມື່ອທຽບກັບສະຖາປັດຕະຍະກໍາອື່ນໆ.

ກົນໄກການຫຼຸດຜ່ອນຜົນບວກທີ່ບໍ່ຖືກຕ້ອງ

ເນື່ອງຈາກຄວາມຈິງທີ່ວ່າສະຖານະການຜິດປົກກະຕິຕ່າງໆເກີດຂື້ນ, ເຊັ່ນດຽວກັນກັບສະຖານະການທີ່ເປັນໄປໄດ້ຂອງການຝຶກອົບຮົມທີ່ບໍ່ພຽງພໍຂອງເຄືອຂ່າຍ neural, ສໍາລັບຮູບແບບການຊອກຄົ້ນຫາຄວາມຜິດປົກກະຕິໄດ້ຖືກພັດທະນາ, ມັນຈໍາເປັນຕ້ອງໄດ້ພັດທະນາກົນໄກສໍາລັບການຫຼຸດຜ່ອນຜົນບວກທີ່ບໍ່ຖືກຕ້ອງ. ກົນໄກນີ້ແມ່ນອີງໃສ່ພື້ນຖານແມ່ແບບທີ່ຖືກຈັດປະເພດໂດຍຜູ້ບໍລິຫານ.

ສູດການຄິດໄລ່ສຳລັບການປ່ຽນເສັ້ນເວລາແບບເຄື່ອນໄຫວ ( DTW algorithm, ຈາກພາສາອັງກິດແບບເຄື່ອນໄຫວເວລາ warping) ຊ່ວຍໃຫ້ທ່ານຊອກຫາການຕອບຮັບທີ່ດີທີ່ສຸດລະຫວ່າງລໍາດັບເວລາ. ໃຊ້ຄັ້ງທໍາອິດໃນການຮັບຮູ້ສຽງເວົ້າ: ໃຊ້ເພື່ອກໍານົດວິທີການສອງສັນຍານການປາກເວົ້າເປັນຕົວແທນຂອງປະໂຫຍກທີ່ເວົ້າຕົ້ນສະບັບດຽວກັນ. ຫຼັງຈາກນັ້ນ, ຄໍາຮ້ອງສະຫມັກໄດ້ຖືກພົບເຫັນສໍາລັບມັນໃນຂົງເຂດອື່ນໆ.

ຫຼັກການຕົ້ນຕໍຂອງການຫຼຸດຜ່ອນຜົນບວກທີ່ບໍ່ຖືກຕ້ອງແມ່ນການເກັບກໍາຖານຂໍ້ມູນຂອງມາດຕະຖານໂດຍການຊ່ວຍເຫຼືອຂອງຜູ້ປະກອບການທີ່ຈັດປະເພດກໍລະນີທີ່ຫນ້າສົງໄສທີ່ກວດພົບໂດຍໃຊ້ເຄືອຂ່າຍ neural. ຕໍ່ໄປ, ມາດຕະຖານການຈັດປະເພດແມ່ນປຽບທຽບກັບກໍລະນີທີ່ລະບົບກວດພົບ, ແລະການສະຫລຸບແມ່ນເຮັດກ່ຽວກັບວ່າກໍລະນີດັ່ງກ່າວແມ່ນບໍ່ຖືກຕ້ອງຫຼືນໍາໄປສູ່ຄວາມລົ້ມເຫຼວ. ບົບ DTW ຖືກນໍາໃຊ້ຢ່າງແນ່ນອນເພື່ອປຽບທຽບສອງຊຸດເວລາ. ເຄື່ອງມືການຫຼຸດຜ່ອນຕົ້ນຕໍແມ່ນຍັງເປັນການຈັດປະເພດ. ຄາດວ່າຫຼັງຈາກລວບລວມກໍລະນີອ້າງອີງຈໍານວນຫລາຍ, ລະບົບຈະເລີ່ມຖາມຜູ້ປະຕິບັດງານຫນ້ອຍລົງຍ້ອນຄວາມຄ້າຍຄືກັນຂອງກໍລະນີສ່ວນໃຫຍ່ແລະການປະກົດຕົວທີ່ຄ້າຍຄືກັນ.

ດັ່ງນັ້ນ, ໂດຍອີງໃສ່ວິທີການເຄືອຂ່າຍ neural ທີ່ອະທິບາຍຂ້າງເທິງ, ໂຄງການທົດລອງໄດ້ຖືກສ້າງຂື້ນເພື່ອຄາດຄະເນຄວາມລົ້ມເຫຼວຂອງລະບົບ "Web-Consolidation". ເປົ້າຫມາຍຂອງໂຄງການນີ້ແມ່ນ, ການນໍາໃຊ້ການເກັບຮັກສາທີ່ມີຢູ່ແລ້ວຂອງການຕິດຕາມຂໍ້ມູນແລະຂໍ້ມູນກ່ຽວກັບຄວາມລົ້ມເຫຼວທີ່ຜ່ານມາ, ເພື່ອປະເມີນຄວາມສາມາດຂອງວິທີການນີ້ສໍາລັບລະບົບຊອບແວຂອງພວກເຮົາ. ໂຄງ​ການ​ຂອງ​ໂຄງ​ການ​ແມ່ນ​ໄດ້​ນໍາ​ສະ​ເຫນີ​ຂ້າງ​ລຸ່ມ​ນີ້​ໃນ​ຮູບ​ທີ 7​.

ຮູບທີ 7. ໂຄງການຄາດຄະເນຄວາມລົ້ມເຫຼວໂດຍອີງໃສ່ການວິເຄາະພື້ນທີ່ metric

ໃນແຜນວາດ, ສອງຕັນຕົ້ນຕໍສາມາດຈໍາແນກໄດ້: ການຄົ້ນຫາສໍາລັບໄລຍະເວລາຜິດປົກກະຕິໃນກະແສຂໍ້ມູນການຕິດຕາມ (metrics) ແລະກົນໄກສໍາລັບການຫຼຸດຜ່ອນຜົນບວກທີ່ບໍ່ຖືກຕ້ອງ. ຫມາຍເຫດ: ສໍາລັບຈຸດປະສົງທົດລອງ, ຂໍ້ມູນແມ່ນໄດ້ຮັບໂດຍຜ່ານການເຊື່ອມຕໍ່ JDBC ຈາກຖານຂໍ້ມູນທີ່ graphite ຈະຊ່ວຍປະຢັດມັນ.
ຕໍ່ໄປນີ້ແມ່ນການໂຕ້ຕອບຂອງລະບົບການຕິດຕາມທີ່ໄດ້ຮັບຜົນມາຈາກການພັດທະນາ (ຮູບ 8).

ຮູບທີ 8. ການໂຕ້ຕອບຂອງລະບົບການຕິດຕາມການທົດລອງ

ການໂຕ້ຕອບສະແດງອັດຕາສ່ວນຄວາມຜິດປົກກະຕິໂດຍອີງໃສ່ metrics ທີ່ໄດ້ຮັບ. ໃນກໍລະນີຂອງພວກເຮົາ, ໃບຮັບເງິນໄດ້ຖືກຈໍາລອງ. ພວກເຮົາມີຂໍ້ມູນທັງຫມົດສໍາລັບຫຼາຍໆອາທິດແລ້ວແລະກໍາລັງໂຫລດມັນເທື່ອລະກ້າວເພື່ອກວດເບິ່ງກໍລະນີຂອງຄວາມຜິດປົກກະຕິທີ່ນໍາໄປສູ່ຄວາມລົ້ມເຫລວ. ແຖບສະຖານະຕ່ໍາຈະສະແດງອັດຕາສ່ວນລວມຂອງຄວາມຜິດປົກກະຕິຂອງຂໍ້ມູນໃນເວລາໃດຫນຶ່ງ, ເຊິ່ງຖືກກໍານົດໂດຍໃຊ້ຕົວເຂົ້າລະຫັດອັດຕະໂນມັດ. ນອກຈາກນີ້, ອັດຕາສ່ວນແຍກຕ່າງຫາກແມ່ນສະແດງສໍາລັບ metrics ທີ່ຄາດຄະເນ, ເຊິ່ງຖືກຄິດໄລ່ໂດຍ RNN LSTM.

ຕົວຢ່າງຂອງການກວດຫາຄວາມຜິດປົກກະຕິໂດຍອີງໃສ່ການປະຕິບັດຂອງ CPU ໂດຍໃຊ້ເຄືອຂ່າຍ neural RNN LSTM (ຮູບ 9).

ຮູບ 9. ການຄົ້ນພົບ RNN LSTM

ກໍລະນີທີ່ງ່າຍດາຍພໍສົມຄວນ, ໂດຍພື້ນຖານແລ້ວເປັນ outlier ທໍາມະດາ, ແຕ່ນໍາໄປສູ່ຄວາມລົ້ມເຫຼວຂອງລະບົບ, ໄດ້ຖືກຄິດໄລ່ສົບຜົນສໍາເລັດໂດຍໃຊ້ RNN LSTM. ຕົວຊີ້ວັດຄວາມຜິດປົກກະຕິໃນຊ່ວງເວລານີ້ແມ່ນ 85-95% ທຸກຢ່າງສູງກວ່າ 80% (ເກນໄດ້ກຳນົດໃນການທົດລອງ) ຖືວ່າເປັນຄວາມຜິດປົກກະຕິ.
ຕົວຢ່າງຂອງການກວດຫາຄວາມຜິດປົກກະຕິໃນເວລາທີ່ລະບົບບໍ່ສາມາດບູດໄດ້ຫຼັງຈາກການປັບປຸງ. ສະຖານະການນີ້ແມ່ນກວດພົບໂດຍ autoencoder (ຮູບ 10).

ຮູບທີ 10. ຕົວຢ່າງຂອງການກວດຫາຕົວເຂົ້າລະຫັດອັດຕະໂນມັດ

ດັ່ງທີ່ທ່ານສາມາດເບິ່ງເຫັນໄດ້ຈາກຕົວເລກ, PermGen ແມ່ນຕິດຢູ່ໃນລະດັບຫນຶ່ງ. autoencoder ໄດ້ພົບເຫັນສິ່ງທີ່ແປກປະຫລາດນີ້ເພາະວ່າມັນບໍ່ເຄີຍເຫັນມັນມາກ່ອນ. ທີ່ນີ້ຄວາມຜິດປົກກະຕິຍັງຄົງຢູ່ 100% ຈົນກ່ວາລະບົບກັບຄືນສູ່ສະພາບການເຮັດວຽກ. ຄວາມຜິດກະຕິແມ່ນສະແດງສໍາລັບທຸກຕົວຊີ້ບອກ. ດັ່ງທີ່ໄດ້ກ່າວມາກ່ອນຫນ້ານີ້, autoencoder ບໍ່ສາມາດ localize ຜິດປົກກະຕິ. ຜູ້ປະຕິບັດງານໄດ້ຖືກຮຽກຮ້ອງໃຫ້ປະຕິບັດຫນ້າທີ່ນີ້ໃນສະຖານະການເຫຼົ່ານີ້.

ສະຫລຸບ

PC "Web-Consolidation" ໄດ້ຢູ່ໃນການພັດທະນາຫຼາຍປີ. ລະບົບແມ່ນຢູ່ໃນສະພາບທີ່ຂ້ອນຂ້າງຄົງທີ່, ແລະຈໍານວນຂອງເຫດການທີ່ບັນທຶກໄວ້ມີຂະຫນາດນ້ອຍ. ຢ່າງໃດກໍ່ຕາມ, ມັນເປັນໄປໄດ້ທີ່ຈະຊອກຫາຄວາມຜິດປົກກະຕິທີ່ນໍາໄປສູ່ຄວາມລົ້ມເຫລວ 5 - 10 ນາທີກ່ອນທີ່ຈະເກີດຄວາມລົ້ມເຫຼວ. ໃນບາງກໍລະນີ, ການແຈ້ງຄວາມລົ້ມເຫລວລ່ວງຫນ້າຈະຊ່ວຍປະຫຍັດເວລາທີ່ກໍານົດໄວ້ທີ່ຖືກຈັດສັນເພື່ອປະຕິບັດ "ການສ້ອມແປງ".

ອີງຕາມການທົດລອງທີ່ໄດ້ປະຕິບັດ, ມັນໄວເກີນໄປທີ່ຈະສະຫຼຸບສະຫຼຸບ. ມາຮອດປະຈຸ, ຜົນໄດ້ຮັບແມ່ນຂັດແຍ້ງກັນ. ໃນອີກດ້ານຫນຶ່ງ, ມັນເປັນທີ່ຊັດເຈນວ່າສູດການຄິດໄລ່ໂດຍອີງໃສ່ເຄືອຂ່າຍ neural ແມ່ນສາມາດຊອກຫາຄວາມຜິດປົກກະຕິ "ທີ່ເປັນປະໂຫຍດ". ໃນອີກດ້ານຫນຶ່ງ, ຍັງມີອັດຕາສ່ວນຫຼາຍຂອງຜົນບວກທີ່ບໍ່ຖືກຕ້ອງ, ແລະບໍ່ແມ່ນຄວາມຜິດປົກກະຕິທັງຫມົດທີ່ກວດພົບໂດຍຜູ້ຊ່ຽວຊານທີ່ມີຄຸນວຸດທິໃນເຄືອຂ່າຍ neural ສາມາດກວດພົບໄດ້. ຂໍ້ເສຍລວມເຖິງຄວາມຈິງທີ່ວ່າໃນປັດຈຸບັນເຄືອຂ່າຍ neural ຕ້ອງການການຝຶກອົບຮົມກັບຄູສອນສໍາລັບການປະຕິບັດງານປົກກະຕິ.

ເພື່ອພັດທະນາລະບົບການຄາດເດົາຄວາມລົ້ມເຫລວຕື່ມອີກແລະນໍາມັນໄປສູ່ສະພາບທີ່ພໍໃຈ, ສາມາດຄາດຄະເນໄດ້ຫຼາຍວິທີ. ນີ້ແມ່ນການວິເຄາະລາຍລະອຽດເພີ່ມເຕີມຂອງກໍລະນີທີ່ມີຄວາມຜິດປົກກະຕິທີ່ນໍາໄປສູ່ຄວາມລົ້ມເຫຼວ, ເນື່ອງຈາກການເພີ່ມເຕີມນີ້ກັບບັນຊີລາຍຊື່ຂອງຕົວຊີ້ວັດທີ່ສໍາຄັນທີ່ມີອິດທິພົນຕໍ່ສະຖານະຂອງລະບົບຢ່າງຫຼວງຫຼາຍ, ແລະການປະຖິ້ມສິ່ງທີ່ບໍ່ຈໍາເປັນທີ່ບໍ່ມີຜົນກະທົບຕໍ່ມັນ. ນອກຈາກນັ້ນ, ຖ້າພວກເຮົາກ້າວໄປໃນທິດທາງນີ້, ພວກເຮົາສາມາດພະຍາຍາມຊ່ຽວຊານ algorithms ໂດຍສະເພາະສໍາລັບກໍລະນີຂອງພວກເຮົາທີ່ມີຄວາມຜິດປົກກະຕິທີ່ນໍາໄປສູ່ຄວາມລົ້ມເຫລວ. ມີວິທີອື່ນ. ນີ້ແມ່ນການປັບປຸງສະຖາປັດຕະຍະກໍາເຄືອຂ່າຍ neural ແລະດັ່ງນັ້ນຈຶ່ງເພີ່ມຄວາມຖືກຕ້ອງຂອງການກວດສອບດ້ວຍການຫຼຸດຜ່ອນເວລາການຝຶກອົບຮົມ.

ຂ້າພະເຈົ້າຂໍຂອບໃຈກັບເພື່ອນຮ່ວມງານຂອງຂ້າພະເຈົ້າທີ່ຊ່ວຍຂ້າພະເຈົ້າຂຽນແລະຮັກສາຄວາມກ່ຽວຂ້ອງຂອງບົດຄວາມນີ້: Victor Verbitsky ແລະ Sergei Finogenov.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com