## Implementasi RESTful untuk Mengurangi Mean Time to Resolve pada Alert Handling
Yadhi Aditya, Setiadi Rachmat, Maisevli Harika * , Mufqi Uwais Nastiar Salim, Dewanto Joyo Pramono
Jurusan Teknik Informatika, Politeknik Negeri Bandung, Bandung, Indonesia Email: 1 yadhi@polban.ac.id, 2 s.rachmat@polban.ac.id, 3,* maisevli@polban.ac.id, 4 mufqi21mufqi@gmail.com,
5 dewantoade11@gmail.com Email Penulis Korespondensi: maisevli@polban.ac.id Submitted 13-10-2022; Accepted 25-10-2022; Published 31-10-2022

## Abstrak
Pemeliharaan layanan IT atau service supaya tetap dapat diakses menjadi salah satu tugas dari tim infrastruktur IT perusahaan. MTTR (Mean Time To Resolve) atau waktu rata-rata yang diperlukan untuk memulihkan service yang sedang bermasalah. MTTR merupakan salah satu aspek penilaian kinerja infrastruktur IT. Peringatan atau  alert muncul sebagai tanda bahwa terdapat  service yang sedang mengalami  masalah.  on-call  engineer  (bagian  dari  tim  infrastruktur  IT)  bertanggung  jawab  untuk  menangani  alert  tersebut. Permasalahan yang terjadi pada PT Sense Health Indonesia berupa repetisi  alert artinya peringatan yang muncul dari permasalahan yang  sudah  pernah  diatasi  atau  diselesaikan  sebelumnya.  Repetisi  alert  ini  terjadi  dalam  jumlah  yang  cukup  besar  sehingga  dapat meningkatkan  nilai  MTTR.  Hasil  penelitian  menunjukkan  integrasi  tools  yang  digunakan  menggunakan  metode  RESTful  mampu mengefisienkan  proses  penanganan  alert  (alert  handling).  Hasil  implementasi  menunjukkan  terjadi  pengurangan  waktu  rata-rata penanganan alert sebesar 78%. Penelitian ini memberikan kontribusi dengan menunjukkan salah satu solusi untuk mengurangi MTTR untuk alert handling.
Kata Kunci: Sistem Integrasi; Alert handling; On-call engineer; Infrastructure IT; Mean Time to Resolve

## Abstract
One of the responsibilities of the company's IT infrastructure team is ensuring that IT services or services stay available. One part of analyzing the performance of IT infrastructure is MTTR (Mean Time to Resolve) or the average time necessary to restore  a service that  is  experiencing  issues.  Warnings  or  alerts  are  shown  when  a  service  is  encountering  difficulties.  As  a  member  of  the  IT infrastructure team, the on-call engineer is responsible for managing alarms. At PT Sense Health Indonesia, difficulties manifest in the form  of  recurrence  alerts,  or  warnings  resulting  from  previously  fixed  or  rectified  issues.  This  warning  is  repeated  with  sufficient frequency to enhance the MTTR value. The findings demonstrated that the integration of tools using the RESTful approach streamlined the  process  of  processing  alerts. The  deployment  led  to  a 78%  decrease  in  the  average  time  required  to  handle  alarms.  This  study contributes by demonstrating one method for decreasing MTTR for alert handling.
Keywords : Integrated System; Alert Handling; On-call Engineer; Infrastructure IT; Mean Time to Resolve

## 1. PENDAHULUAN
Peran  dari  seorang Infrastructure Engineer di  antaranya  adalah  mendesain,  membangun,  melakukan deploy ,  dan memelihara/ maintaining infrastruktur IT [1] terlepas menggunakan teknologi terkini atau tidak. Infrastructure engineer harus bisa menjamin menunjang bisnis perusahaan yang berkaitan dengan sistem IT  ( service ) berfungsi secara efisien. Karena sistem IT pada sebuah perusahaan biasanya berskala besar dan kompleks, kegagalan merupakan hal yang tidak dapat dihindarkan [2]. Service yang gagal dapat disebabkan berbagai hal, seperti hardware outages, software bugs, atau perubahan load user [3], [4]. PT  Sense  Health  Indonesia,  terdapat Infrastructure engineer yang  bertugas  untuk menjaga database agar  tetap dapat digunakan setiap saat, baik untuk menyimpan atau mengambil data. Sense Health adalah perusahaan multinasional yang berkantor pusat di kota Rotterdam, Belanda. Pada cabang Indonesia, Sense Health Indonesia infrastructure engineer dibagi menjadi dua profesi yaitu problem management engineer dan on-call engineer . Tugas dari problem management engineer adalah menyelesaikan masalah yang ada pada daftar dokumentasi alert ( problem record ) untuk menghasilkan solusi  ( workaround )  sehingga  masalah  yang  terjadi  dapat  diselesaikan.  Sedangkan on-call  engineer bertugas  untuk memantau ketersediaan ( availability ) dari setiap layanan ( service ) yang ada di perusahaan. Saat  ini  banyak  sekali tools yang  dikembangkan  untuk  memudahkan  pengguna  menyelesaikan  permasalahan bidang IT-nya. Sebut saja ada (1) Red Hat CodeReady Workspaces [5] untuk mengotomatiskan sepenuhnya penyebaran file teks/biner dari server target, (2) GitHub [6] dan BitBucket [7] untuk source control dengan fungsi tambahan lain pada masing-masingnya,  (3)  Ansible  AWS  [8]  yang  mampu  untuk  mendefinisikan,  menerapkan,  dan  mengelola  berbagai macam layanan platform cloud AWS, (4) Opsgenie [9] merupakan tools untuk incident management pada sistem IT, dan lain sebagainya. Kadang untuk bekerja lebih efektif dibutuhkan tools lain. Hal ini juga sama dengan yang terjadi pada Sense Health Indonesia. Opsgenie digunakan untuk memantau service , problem record dicatatkan pada GitHub Issues, kemudian eksekusi workaround melalui Ansible AWX. On-call engineer memantau service menggunakan Opsgenie. Apabila terjadi sesuatu pada service maka akan ada alert dari Opsgenie, on-call engineer mencari solusi pada problem record di GitHub Issues karena akan double effort jika harus melakukan investigasi terlebih dahulu sebelum menyelesaikan permasalahan. Apabila solusi dari alert telah ada pada problem record , maka on-call engineer akan langsung mengeksekusi workaround yang didapat dari problem record melalui Ansible AWX. Namun apabila alert belum mempunyai workaround pada problem record di GitHub Issues, maka
on-call engineer perlu melakukan investigasi terhadap masalah yang terjadi pada alert , kemudian menuliskan workaround baru ke dalam repository kemudian mengeksekusinya. Proses penyelesaian alert ini disebut sebagai alert handling .
Tabel 1. Daftar Alert Beserta Kemunculannya Tahun 2022 Periode Januari - Juni
No. Nama Alert Jumlah Kemunculan 1. HAProxySlowResponse 597 2. HighIO 466 3. HAProxyHighErrorRate 393 4. InstanceDown 324 5. HAProxyBackendDown 297 6. NiceDayAlphaChatHealthCheckDown 280 7. NiceDayBetaChatHealthCheckDown 234 8. InfrastructureServiceDown 198 9. NiceDayAlphaServiceDown 171
Terlihat pada Tabel 1 ada beberapa jenis alert yang muncul pada Sense Health Indonesia dalam jumlah yang tinggi. Hal ini berarti on-call engineer harus melakukan proses mencari problem record pada GitHub Issues dari awal sampai akhir, untuk mendapatkan workaround dari alert yang telah terjadi. Proses pencarian problem record ini harus dilakukan setiap kali ada alert (repetisi) Akibatnya Mean Time to Resolve (MTTR) menjadi tinggi. Nilai MTTR yang tinggi berarti waktu yang cukup lama diperlukan sebuah service yang bermasalah untuk kembali bekerja secara normal. Penelitian terdahulu yang membahas integrasi tools untuk pengembangan perangkat lunak [10]. Pada penelitian terdahulu ini membahas mengenai integrasi beberapa tools yang dibutuhkan untuk pengembangan perangkat lunak akan tetapi tidak diintegrasikan sesuai lima dimensi yang dikemukakan Wasserman [11]. Ide penelitian terdahulu ini mengatur development proses  dan  mengakses  data  pada  proyek  menggunakan  beberapa tools .  Pada  penelitian  ini  ide  untuk mengintegrasikan tools digunakan untuk menyelesaikan permasalahan alert handling pada incident management system yang  dimiliki  Sense  Health  Indonesia.  Akan  tetapi  ada  masalah tool yang  digunakan  tidak compatible satu  sama  lain karena  dikembangkan  oleh  pengembang  yang  berbeda.  Sehingga  solusi  untuk tool  integration tidak  memungkinkan, sebagai gantinya adalah service dari tool-tool tersebut dihubungkan. Representational state transfer (REST) memungkinkan untuk menjadi konektor data-data. REST atau REST web API  merupakan  gaya  arsitektur  yang  paling  banyak  digunakan service-oriented  computing saat  ini  [12]. Web  Service adalah  komponen software yang  dapat  diakses  melalui  jaringan  dan platform-independent dari Service  Oriented Architecture (SOA)  untuk  melakukan  tugas  tertentu. Web  service memungkinkan  untuk  memanggil  informasi  pada aplikasi  yang  dihubungkan  oleh  Internet.  SOA  mendukung  berbagai  karakteristik  untuk  membangun  model  berbasis broker yang dikenal sebagai SOA 1.0. [13].
Pendekatan yang dipilih berbeda dengan penelitian terdahulu yaitu menggunakan RESTful web service integration algorithm.  Opsgenie  yang  digunakan  untuk  memantau service dan  mengirim alert jika  ada service yang  bermasalah. Permasalahan  yang  muncul  ini  akan  dicek  pada problem  record pada  GitHub  Issues.  Terakhir  eksekusi workaround melalui Ansible AWX. Harapannya dengan solusi ini akan mengurangi waktu rata-rata penanganan alert oleh on-call engineer artinya MTTR akan berkurang [14], [15].

## 2. METODOLOGI PENELITIAN
Integration tools pada  suatu  perusahaan  merupakan  solusi  cepat  untuk  menangani  permasalahan  yang  disebabkan penggunaan pada tools . Solusi ini cepat karena tetap menggunakan tools yang ada dan tidak perlu melakukan perubahan pada sistem keseluruhan.

## 2.1 Tahapan Penelitian
Tahapan penelitian diatur tahap demi tahap secara runut untuk menghindari kesalahan dalam pemilihan solusi terhadap alert handling pada incident management system PT. Sense Health Indonesia. Tahapan-tahapan dapat diuraikan sebagai berikut:
a. Tahap identifikasi masalah
Pengenalan permasalahan pada penelitian ini diperoleh dari stack holder sendiri. PT. Sense Health Indonesia layaknya perusahaan lain memiliki banyak sekali service yang running per harinya. Hal ini memungkinkan munculnya alert yang sama muncul berulang kali dalam jumlah yang banyak (repetisi alert ). Dapat dilihat pada Tabel 1, dalam periode enam bulan saja alert sejenis yang muncul bisa sampai ratusan. On-call engineer harus mencari workaround yang tepat dari history alert yang telah ada. Hal ini memang membutuhkan waktu tambahan untuk menyelesaikan permasalahan, akan tetapi lebih cepat daripada mencoba mencari solusi dari awal. Walaupun sudah ada catatan workaround (solusi) akan tetapi stack holder masih merasa ada peluang MTTR dapat diturunkan.
b. Tahap perumusan masalah
Setelah  masalah  ditemukan  dan  dikenali.  Selanjutnya  dirumuskan  supaya  mudah  untuk  dipahami  dan  diharapkan ditemukan  solusi  yang  tepat  untuk  hal  tersebut.  Solusi  yang  paling  mungkin  tanpa  mengubah  sistem  secara
keseluruhan  adalah integration  tools. Integrasi tools yang  telah  digunakan  artinya  tetap  dengan  cara  kerja  yang sekarang akan tetapi bagian memeriksa catatan workaround dapat dikurangi. Pendekatan ini akan mengurangi waktu on-call engineer untuk menyelesaikan penanganan alert . c. Tahap analisis sistem berjalan
Walaupun  tahap  identifikasi  masalah  sudah  berhasil  menemukan  permasalahan,  akan  tetapi  dibutuhkan  tahapan tersendiri untuk memahami setiap tools dan spesialisasi penggunaan pada stack holder . Tahap ini sangat kritis karena harus berurusan dengan corporate confidential dari sistem yang digunakan. d. Perancangan sistem
Sistem dirancang dengan pendekatan software development. Jadi ada diagram-diagram untuk pemodelan. e. Implementasi dan pengujian
Implementasi  sistem  diiringi  dengan  pengujian.  Pengujian  ini  dilakukan  untuk  memastikan  sistem  dapat  bekerja dengan baik, selain itu diperlukan untuk mencari kesalahan pada sistem yang dibangun. Pengujian sistem terdiri dari unit testing dan integration testing . f. Analisis hasil
Implementasi dan pengujian dianalisis untuk penarikan kesimpulan terhadap penelitian serta prediksi pengembangan penelitian ke depan.

## 2.2 RESTfull
Teknologi yang digunakan untuk mengembangkan layanan web dan untuk berkomunikasi dengan layanan dikenal sebagai Representational State Transfer , atau disingkat REST. Kelebihan yang REST daripada web service lainnya adalah: a. Ligh-weight [13], [16]: Tidak adanya enkripsi atau deskripsi overhead baik dalam permintaan HTTP maupun pesan respons adalah yang membuat REST memiliki reputasi yang ringan.
b. Simplicity [13],  [16]:  REST  secara  signifikan  lebih  mudah  digunakan  karena  fakta  bahwa  itu  tidak  memerlukan deklarasi antarmuka apa pun seperti yang dilakukan layanan web lainnya.

## 2.2.1 Prinsip REST
Konsep Representational State Transfer (REST) pada tahun 2000 [13]. Prinsip mengembangkan arsitektur REST melalui Internet dengan memanfaatkan RESTful web service . Prinsip REST (REST constrain ):
a. Identification  of  Resources  through URI:  Arsitektur  REST  mendefinisikan  dan  mengacu  segala  sesuatu  sebagai resource ,  menentukan resource merupakan  tantangan  tersendiri  pada  REST.  Setiap resource memiliki Uniform Resource Identifier (URI) yang unik. Resource dipasang di server dan menggunakan URI sehingga dapat diakses dari seluruh dunia [13], [16].
b. Manipulation  of  Resources  through  Representations :  Prinsip  arsitektur  REST  diwujudkan  dengan  memanfaatkan protokol  HTTP.  Karena  itu,  dimungkinkan  untuk  menggunakan  antarmuka  yang  sama  untuk  membangun  setiap resource dengan  melakukan  serangkaian  aktivitas  yang  telah  ditentukan.  Setelah resource yang  perlu  diakses menggunakan URI, setiap metode kemudian menjalankan operasi unik untuk menghasilkan pesan respons permintaan HTTP (PUT, GET, POST, dan DELETE) [13], [16].
c. Self-Descriptive Messages : Karena sifat resource yang berbeda, pesan permintaan dapat ditransfer dengan representasi HTML, XML, dan JSON. Pesan yang dikirim melalui REST diformat sedemikian rupa sehingga mudah dipahami oleh klien maupun server. Penting untuk menemukan representasi sumber daya yang sesuai dengan permintaan yang diberikan, dan permintaan itu sendiri harus di -encode ke request yang dapat menghasilkan pesan read-only atau write- only . d. Stateful  interactions  through  hyperlinks :  Setiap  interaksi  dengan resource merupakan stateless ,  artinya request message merupakan self-contained .  Beberapa  teknik  untuk  bertukar state antara  lain  URI rewriting , cookies ,  dan hidden form model . State dapat ditambahkan pada response message .

## 2.2.2 Kelebihan REST web service
Kelebihan REST web service antara lain:
a. Easy-Accessibility : URI yang digunakan untuk tujuan mengidentifikasi RESTful WS dapat diedarkan dan dibagikan dengan dedicated client atau aplikasi umum untuk digunakan kembali. Representasi resource di RESTful web services dan URI memudahkan penggunaan web service ini [13]. b. Scalability :  Kemampuan RESTful Web  Services untuk  mendukung caching serta  paralelisasi  dan  partisi  pada  URI meningkatkan daya  tarik  REST.  Hasil  GET,  yang  tidak  menghasilkan  efek  samping dan dapat  di- cache ,  disimpan dengan cara yang sama dengan halaman web pada proxy , gateway , dan Content Delivery Networks (CDN). Selain itu, layanan web RESTful menawarkan metode yang langsung dan efisien untuk mendukung penyeimbangan beban yang didasarkan pada partisi URI [13].

## 2.3 Unit Testing
Unit testing merupakan salah satu jenis pengujian perangkat lunak. Melibatkan pengujian setiap komponen perangkat lunak  [17].  Selama  proses  pengembangan  aplikasi,  pengujian  komponen  individual  dari  produk  perangkat  lunak dilakukan.  Setiap  komponen  dapat  berfungsi  sebagaimana  seharusnya.  Secara  umum,  unit  testing  dilakukan  oleh
pengembang  perangkat  lunak.  Setiap  modul  independen  diuji  oleh  pengembang  untuk  menentukan  apakah  ada permasalahan atau tidak.

## 2.2 Integration Testing
Proses pengujian antarmuka antara dua unit perangkat lunak atau modul disebut sebagai integration testing . Keakuratan antarmuka adalah perhatian utama dari bagian proses ini. Tujuan pengujian integrasi adalah untuk menemukan kelemahan integrasi berinteraksi satu sama lain [17]. Pengujian integrasi dilakukan setelah semua modul individu telah divalidasi oleh unit testing .

## 3. HASIL DAN PEMBAHASAN
Pada bagian ini berisi hasil dan pembahasan dari penerapan REST untuk integration tool .

## 3.1 Perancangan
Sistem  dirancang  sesuai  dengan requirement yang  telah  disusun  pada  tahap  analisis  dan  disesuaikan  dengan teknologi/ tools hasil studi pustaka. Pemodelan arsitektur sistem dengan menggunakan C4 Model. C4Model merupakan teknik penggambaran diagram arsitektur sistem yang mengutamakan abstraksi terlebih dahulu kemudian didekomposisi menjadi bagian-bagian yang lebih detail [18]. Dekomposisi tersebut terbagi ke beberapa level seperti berikut:
a. C1: Context : Level 1 disebut dengan System Context . Merupakan abstraksi yang menggambarkan arsitektur sistem secara keseluruhan.
Gambar 1. Diagram C4Model sistem terintegrasi di level system context
b. C2: Containers : Pada level ini software system didekomposisi menjadi bagian-bagian yang disebut dengan container , merepresentasikan suatu aplikasi atau suatu data store .
Gambar 2. Diagram C4Model sistem terintegrasi level container
c. C3: Components : Pada level 3, container didekomposisi menjadi beberapa component . Satu component menjelaskan satu fungsionalitas yang dimiliki oleh container .
Gambar 3. Diagram C4Model sistem terintegrasi level component
d. C4: Code :  Pada  level  terbawah  atau  level  4, component didekomposisi  menjadi  sekumpulan code .  Penggambaran arsitektur menggunakan UML. Interaksi yang terjadi pada sistem adalah sebagai berikut.
1. Pembuatan problem record : interaksi antara Opsgenie API, GitHub API, dan  sistem NestJS App ketika proses pada use case membuat problem record baru
Gambar 4. Diagram Use Case Membuat Problem Record Baru
2. Penyimpanan workaround :  Diagram  yang  menunjukkan  interaksi  antara  Opsgenie  API,  GitHub  API,  Ansible AWX API, dan sistem NestJS App ketika proses pada use case menyimpan workaround baru
3. Pengiriman notifikasi hasil eksekusi workaround :
Gambar 6. Diagram use case menerima notifikasi hasil job execution
4. Pengeksekusian workaround : Diagram yang menunjukkan interaksi antara Opsgenie API, Ansible AWX API, dan sistem NestJS App ketika proses pada use case menjalankan action .
Perancangan database dapat dilihat pada diagram Entity Relationship (ER).
Gambar 2. Diagram entity relationship (ER) kebutuhan data Pengujian

## 3.2 Pengujian
Pengujian dibagi menjadi dua yaitu dengan unit testing dan integration testing . Unit testing bertujuan untuk memastikan setiap  bagian  atau  komponen  pada  NestJS  App  bekerja  sesuai  dengan  apa  yang  diharapkan. Unit  testing dilakukan menggunakan Jest. Setelah setiap bagian atau komponen NestJS App diuji pada unit testing maka dilanjutkan dengan integration  testing .  Target  pengujian  terdiri  dari  modul database ,  modul  GitHub,  modul  Ansible  AWS,  dan  modul opsigenie. Hasil pengujian unit testing dapat dilihat pada Tabel 1, dan hasil pengujian integration testing pada Tabel 2.
Tabel 1. Hasil Pengujian dengan unit testing
No. Nama Services Jumlah Test Case Test Case Berhasil  Test Case Gagal  Hasil Pengujian 1. Database 11 11 0 100% 2. GitHub 3 3 0 100% 3. Ansible AWX 6 6 0 100% 4. Opsgenie 11 11 0 100%
Gambar 3. Hasil code coverage berdasarkan pengujian dengan unit testing
Berdasarkan hasil code coverage tersebut dapat dilihat bahwa modul database memiliki coverage sebesar 76,04%, GitHub sebesar 94%, Ansible AWX sebesar 60,27%, sedangkan Opsgenie sebesar 63,63%. Hal ini dikarenakan test case yang dibuat belum menjangkau validasi-validasi yang ada sehingga hasil code coverage tidak mencapai 100%.
Tabel 2. Hasil pengujian dengan integration testing No. Requirement Jumlah Test Case Test Case Berhasil Test Case Gagal Persentase Hasil Pengujian 1. Pengguna dapat membuat problem record baru langsung pada alert di Opsgenie 2 2 0 100% 2. Pengguna dapat melihat hasil beserta tautan dari pembuatan problem record baru pada kolom note di Opsgenie 2 2 0 100% 3. Pengguna dapat mengakses tautan menuju problem record yang ada di kolom description untuk alert yang sudah mempunyai problem record 2 2 0 100%
4. Pengguna dapat menyimpan workaround
baru beserta datanya dengan menggunakan kolom komentar issue di GitHub 13 13 0 100% 5. Pengguna dapat menggunakan template literals untuk mengambil value dari labels/tags sebagai data workaround 2 2 0 100%
6. Pengguna dapat mengeksekusi workaround langsung menggunakan custom action milik alert di Opsgenie 8 8 0 100% 7. Pengguna dapat melihat notifikasi hasil eksekusi workaround pada kolom note di alert beserta tautan untuk menuju job yang ada di Ansible AWX 2 2 0 100%
8. Pengguna dapat menghapus workaround yang telah tersimpan untuk suatu problem record 5 5 0 100% 9. Pengguna dapat menambahkan label/tag baru untuk suatu problem record 3 3 0 100% 10. Pengguna dapat menghapus label/tag dari suatu problem record 3 3 0 100% 11. Pengguna dapat melihat daftar workaround yang tersimpan untuk suatu problem record 2 2 0 100%

## 3.3 Perbandingan MTTR
Analisis  MTTR  ini  dilakukan  terhadap  sistem  sebelum  dan  sesudah  implementasi  REST  API.  Nilai  MTTR  tersebut didapatkan berdasarkan perhitungan dari sistem milik Opsgenie yang dipakai perusahaan. Opsgenie biasanya melaporkan nilai MTTR untuk setiap bulannya. Begitu juga perhitungan yang dipakai untuk mengukur nilai MTTR setelah adanya sistem  terintegrasi.  Pengukuran  nilai  MTTR  sebelum  adanya  sistem  terintegrasi  dilakukan  selama  tiga  bulan.  Dengan hasil seperti Tabel 3.
Tabel 3. Hasil nilai MTTR sebelum tools terintegrasi Bulan ke- MTTR (menit) 1 137 2 142 3 264
Tabel 4 menunjukkan sistem setelah diimplementasi REST API sebagai middleware .
Tabel 4. Hasil nilai MTTR setelah tools terintegrasi Bulan ke- MTTR (menit) 1 55 2 60 3 21

## 4. KESIMPULAN
Penelitian ini dapat menunjukkan integrasi terhadap tool bertujuan untuk meningkatkan efisiensi waktu yang diperlukan dalam  proses alert  handling di  PT  Sense  Health  Indonesia  berhasil  dan  berfungsi  sebagaimana  mestinya.  Untuk meningkatkan  efisiensi  waktu  pada  proses alert  handling ,  konsep  REST  API  terbukti  dapat  digunakan  untuk
menghubungkan beberapa elemen sistem. Integrasi ini terbukti meningkatkan MTTR. Dapat dilihat pada Tabel 3  rata- rata MTTR  adalah 200, sedangkan pada Tabel 4 rata-rata MTTR  adalah 45. Berdasarkan hasil perbandingan tersebut, dapat disimpulkan bahwa sistem terintegrasi berhasil menurunkan nilai MTTR di perusahaan hingga 78%. Semakin kecil nilai MTTR maka semakin efisien juga proses alert handling yang dilakukan. Hal ini juga dapat memperkuat dugaan bahwa  beberapa  faktor  yang dapat  memperlambat  proses alert handling yang  disebutkan  pada  analisis alert handling dapat berpengaruh terhadap waktu proses alert handling ketika terjadi banyaknya repetisi alert . Penurunan MTTR sebesar 78% ini menunjukkan efisiensi waktu untuk menyelesaikan alert handling . Untuk meningkatkan efisiensi alert handling ini dapat ditambahkan machine learning untuk beberapa bagian: (1) pengaplikasian workaround dapat dilakukan benar- benar secara otomatis, (2) mencari solusi untuk alert sendiri. Pengaplikasian machine learning ini memungkinkan sistem menjadi fully automated system .

## REFERENCES
[1] “Infrastructure Engineer.” https://www.fieldengineer.com/skills/what-is-an-infrastructure-engineer#:~:text=Infrastructure Engineers are responsible for,size function efficiently and seamlessly. (accessed Aug. 11, 2022).
[2] Q. Lin, H. Zhang, J. G. Lou, Y. Zhang, and X. Chen, “Log clustering based problem identification for online service systems,” in Proceedings - International Conference on Software Engineering, 2016, pp. 102–111. doi: 10.1145/2889160.2889232.
[3] X. Zhou et al., “Latent error prediction and fault localization for microservice applications by learning from system trace logs,” in  ESEC/FSE  2019  -  Proceedings  of  the  2019  27th  ACM  Joint  Meeting  European  Software  Engineering  Conference  and Symposium on the Foundations of Software Engineering, 2019, pp. 683–694. doi: 10.1145/3338906.3338961.
[4] X. Zhou et al., “Fault Analysis and Debugging of Microservice Systems: Industrial Survey, Benchmark System, and Empirical Study,” IEEE Trans. Softw. Eng., vol. 47, no. 2, pp. 243–260, 2021, doi: 10.1109/TSE.2018.2887384.
[5] “Red Hat CodeReady Workspaces.” https://developers.redhat.com/products/openshift-dev-spaces/overview (accessed Aug. 11, 2022).
[6] “GitHub.” https://github.com/ (accessed Aug. 11, 2022).
[7] “BitBucket.” https://bitbucket.org/ (accessed Aug. 11, 2022).
[8] “INTEGRATION:  Ansible  and  AWS.”  https://www.ansible.com/integrations/cloud/amazon-web-services  (accessed  Aug.  11, 2022).
[9] “On-call and alert management to keep services always on.” https://www.atlassian.com/software/opsgenie (accessed Aug. 11, 2022).
[10]  F. Calefato and F. Lanubile, “A hub-and-spoke model for tool integration in distributed development,” in  Proceedings - 11th IEEE International Conference on Global Software Engineering, ICGSE 2016, 2016, pp. 129–133. doi: 10.1109/ICGSE.2016.12.
[11]  A. L. Wasserman, “Tool integration in software engineering environments,” Lect. Notes Comput. Sci. (including Subser. Lect. Notes Artif. Intell. Lect. Notes Bioinformatics), vol. 467 LNCS, pp. 137–149, 1990, doi: 10.1007/3-540-53452-0_38.
[12]  P. K. Venkatesh, S. Wang, F. Zhang, Y. Zou, and A. E. Hassan, “What do client developers concern when using web APIs? An empirical study on developer forums and stack overflow,” in Proceedings - 2016 IEEE International Conference on Web Services, ICWS 2016, 2016, pp. 131–138. doi: 10.1109/ICWS.2016.25.
[13]  M.  H.  Bohara,  M.  Mishra,  and  S.  Chaudhary,  “RESTful  Web  Service  integration  using  Android  platform,”  2013.  doi: 10.1109/ICCCNT.2013.6726550.
[14]  M.  Hasan,  “Design  and  Implementation  of  an  Automated  IT  Incident  Management  System  for  Small  and  Medium-Sized Enterprises,” 2021.
[15]  A. Kelkar, U. Naiknaware, S. Sukhlecha, A. Sanadhya, M. Natu, and V. Sadaphal, “Analytics-based solutions for improving alert management service for enterprise systems,” in Proceedings - IEEE 13th International Conference on Data Mining Workshops, ICDMW 2013, 2013, pp. 219–227. doi: 10.1109/ICDMW.2013.166.
[16]  S.  Sasirekha,  I.  J.  L.  Paul,  and  S.  Swamynathan,  “An  API  Centric  Smart  Kitchen  Application,”  2018.  doi: 10.1109/ICCCSP.2018.8452850.
[17]  H. K. Brar and P. J. Kaur, “Differentiating integration testing and unit testing,” in 2015 International Conference on Computing for Sustainable Global Development, INDIACom 2015, 2015, pp. 796–798.
[18]  S. Brown, The C4 model for visualising software architecture. 2018. [Online]. Available: https://c4model.com/%0Ahttps://c4model.com/%0Ahttps://www.infoq.com/articles/C4-architecture- model/%0Ahttps://c4model.com/