Menjaga Keamanan Bangunan: Ketersediaan Tinggi dalam Sistem Pemeliharaan dan Keamanan

Menjaga Keamanan Bangunan: Ketersediaan Tinggi dalam Sistem Pemeliharaan dan Keamanan

Dalam episode iniTFiR: Mari Bicara, pembawa acara Swapnil Bhartiya berbicara dengannyaDave Bermingham, Direktur Kesuksesan Pelanggan di SIOS Technology, tentang mengapa ketersediaan tinggi dan ketahanan sangat penting bagipemeliharaan bangunan dan sistem keamananBermingham menjelaskan bagaimana sistem-sistem ini berbeda dari, tetapi sering berinteraksi dengan, teknologi bangunan lainnya, dan mengapa pengoperasian tanpa gangguan sangat penting untuk keselamatan penghuni dan fungsionalitas bangunan. Percakapan ini mengeksplorasi bagaimana organisasi dapat menyeimbangkan keamanan dengan aksesibilitas, peran teknologi baru seperti AI, pembelajaran mesin, dan IoT dalam meningkatkan keandalan, dan praktik terbaik untuk memastikan ketersediaan sistem melalui redundansi, pemantauan, dan perencanaan risiko.

Penulis: Beth Winkowski, Hubungan Masyarakat SIOS Technology Corp.

Direproduksi dengan izin dariSIOS

Merancang Ketersediaan Tinggi Melalui Modularitas dan Abstraksi

Merancang Ketersediaan Tinggi Melalui Modularitas dan Abstraksi

Sejauh ini, seri ini telah mengeksplorasi persamaan antara desain teknis dan retorika. “Retorika” dari solusi teknis, strategi mengkomunikasikan makna dan tujuan, disajikan melalui pola dan konsep desain. Pola dan konsep desain tersebut berfungsi sebagai fondasi konseptual, di mana makna tersebut diterjemahkan ke dalam bentuk terapan ketika dipraktikkan selama implementasi.

Seperti yang telah dibahas sebelumnya, keberlanjutan dan integritas dari hal inilandasan konseptualsangat penting untuk memastikan bahwa solusi selalu terjaga pada standar yang kondusif untuk pemeliharaan, peningkatan, dan keandalan jangka panjang. Eksternalfaktor-faktor yang memengaruhi desain suatu solusiHal ini menantang tujuan untuk menjunjung tinggi landasan konseptual yang dikemukakan dalam desain suatu solusi. Faktor-faktor eksternal ini dapat bertentangan dengan prinsip-prinsip yang ada, dan oleh karena itu, alat, aplikasi, dan platform yang digunakan dalam suatu solusi harus dipilih dengan cermat.

Pada bagian ketiga dan terakhir dari seri blog ini, modularitas dan abstraksi akan dieksplorasi sebagai cara untuk menetapkan batasan dan memastikan bahwa proyek-proyek dengan cakupan luas dapat terus menuai manfaat dari desain yang terstruktur dengan baik dan memiliki landasan retorika yang kuat.

Prinsip-prinsip Desain Ketersediaan Tinggi: Mengapa Modularitas dan Abstraksi Penting

Sebelum membahas modularisasi dan abstraksi sebagai strategi, penting untuk memahami mengapa hal-hal ini perlu diterapkan. Secara umum, dengan sebuah analogi, seorang pembicara yang mencoba meyakinkan audiensnya untuk menyetujui rencananya mungkin perlu terlebih dahulu menguraikan beberapa poin dasar. Dengan demikian, setiap pilar dasar argumennya dikemukakan dan dibenarkan.

Pembicara pertama-tama harus membangun dasar “A menyiratkan B” dan “C menyiratkan D”, yang kemudian dapat digunakan untuk membentuk argumen “B dan D menyiratkan E”. Strategi ini memastikan bahwa penalaran di mana “A menyiratkan B” tidak saling mencemari dan mengurangi poin terpisah “C menyiratkan D”. Strategi ini sering digunakan karena memungkinkan setiap komponen argumen pembicara untuk berdiri sendiri. Jika argumen “C menyiratkan D” cacat, argumen tersebut dapat diperbaiki sementara argumen “A menyiratkan B” tetap valid.

Alasan di balik struktur ini sama dengan alasan mengapa sistem teknis bersifat terdesentralisasi – masalah dalam sistem titik penjualan dapat diperbaiki tanpa perlu memperluas upaya perbaikan ke basis data, API, arsitektur jaringan, dan sebagainya. Strategi yang disebutkan di atas, tentu saja, mengacu pada konsep modularitas dan abstraksi.

Modularitas dalam Arsitektur Ketersediaan Tinggi

Pertama, membahas modularitas, ini adalah praktik menciptakan sistem dari komponen-komponen yang mandiri. Dalam pengertian retorika, argumen “A menyiratkan B” dan “C menyiratkan D” hanyalah modul-modul penalaran yang dirangkai menjadi argumen secara keseluruhan.

Secara teknis, komponen yang dimodularisasi (seperti sistem point of sale pada contoh sebelumnya) memungkinkan masalah diatasi sepenuhnya di dalam modul tempat masalah tersebut berasal. Setiap modul dalam solusi bertindak sebagai blok bangunan, dan masalah dalam satu blok bangunan dapat diselesaikan tanpa membongkar seluruh solusi.

Abstraksi sebagai Strategi untuk Desain Infrastruktur yang Dapat Diperluas

Berkaitan erat dengan modularitas adalah “abstraksi”. Abstraksi adalah praktik untuk memastikan bahwa desain solusi keseluruhan bersifat independen dan tidak bergantung pada desain modul-modul yang membentuk solusi keseluruhan tersebut.

Lebih lanjut, abstraksi sebagai strategi desain juga menyatakan bahwa setiap modul bersifat independen dan tidak bergantung pada desain modul lainnya. Ketika suatu solusi dirancang untuk menggunakan elemen-elemen yang diabstraksikan, elemen-elemen ini dapat digunakan kembali dan diterapkan dalam kasus penggunaan yang memungkinkan pemahaman diperluas di seluruh proyek.

Merancang Ketersediaan Tinggi yang “Tidak Mengganggu”

Ketika desain dibangun dari komponen modular, batasan-batasan akan digambar. Batasan-batasan ini memastikan bahwa setiap modul dapat “tidak mengganggu” modul-modul lainnya. Ketika komponen-komponen tersebut diabstraksikan, isi setiap modul dapat dipahami dengan lebih mudah.

Pada gilirannya, batasan-batasan tersebut berfungsi sebagai struktur yang memungkinkan pemahaman desain, dan abstraksi di dalam batasan-batasan ini berfungsi sebagai titik masuk untuk memahami dasar-dasar kasus penggunaan. Struktur yang disediakan melalui modularitas dan abstraksi mencerminkan peran retorika dalam menyediakan kerangka kerja yang memungkinkan pemahaman tujuan.

Mengelola Arsitektur Jaringan Kompleks dengan Solusi HA Modular

Seiring dengan pengembangan solusi teknis untuk mengatasi masalah yang lebih kompleks, kebutuhan akan kerangka kerja yang solid dalam desain solusi tersebut juga meningkat. Arsitektur jaringan, yang seringkali merupakan puncak dari banyak solusi yang kompleks dengan sendirinya, berfungsi sebagai contoh fantastis dari masalah yang semakin kompleks dan kebutuhan yang semakin besar akan kerangka kerja yang solid dalam desain. Lebih jauh lagi, arsitektur jaringan seringkali mengalami pertumbuhan yang berkelanjutan karena harus menyerap jaringan sistem yang luas yang berkontribusi pada tujuan bisnis yang berkembang.

Sebagai lapisan tambahan di atasnya, arsitektur solusi kemudian harus menerapkan solusi untukKetersediaan Tinggi dan/atau Pemulihan BencanaHal ini menciptakan titik rawan bagi munculnya konflik desain, tetapi dapat dengan mudah diatasi dengan strategi modularisasi dan abstraksi.

Menerapkan Modularitas dan Abstraksi dengan Perangkat Lunak Ketersediaan Tinggi SIOS

Manfaat dariPerangkat lunak Ketersediaan TinggiHal ini dapat dicapai tanpa beban kerumitan dan solusi yang rumit. SIOS LifeKeeper, sebagai contoh alat Ketersediaan Tinggi yang sesuai dengan desain, dibuat sedemikian rupa sehingga prinsip-prinsip operasinya dapat menyatu dengan mulus dengan lingkungan tempat ia digunakan.

LifeKeeper bersifat modular, karena tidak memaksakan persyaratan di luar sistem yang dilindungi LifeKeeper. LifeKeeper juga memfasilitasi abstraksi komponen infrastruktur menjadi elemen-elemen yang lebih kecil – sistem yang bekerja sama untuk memastikan ketersediaan dikelompokkan ke dalam sebuah “cluster”.

Melalui abstraksi ini, retorika lingkungan tetap kuat – memahami susunan satu klaster meletakkan dasar untuk memahami semua klaster. Lapisan desain dapat dipahami sesuai tujuannya; tidak perlu tanda bintang dan pertimbangan khusus tentang bagaimana implementasi berbeda di seluruh desain. Karena klaster bertindak secara independen dari klaster lain atau komponen solusi eksternal, batasan dapat ditarik di mana elemen desain dari setiap lapisan masing-masing terkandung, menghindari konflik dengan lapisan infrastruktur lainnya.

Membangun Infrastruktur Tangguh Jangka Panjang dengan SIOS Protection Suite

Seperti halnya perangkat lunak atau alat lainnya,SIOS Protection Suite(SIOS LifeKeeper dan/atau SIOS DataKeeper) memengaruhi desain lingkungan tempat mereka digunakan. Meskipun pola-pola ini diperkenalkan karena adanya lingkungan yang dilindungi oleh LifeKeeper dan DataKeeper, SIOS LifeKeeper dan SIOS DataKeeper dengan cermat memilih pola-pola yang digunakan untuk memastikan bahwa pola-pola ini memungkinkan abstraksi dan modularitas dalam solusi secara keseluruhan. Sebagai hasil dari abstraksi berlapis yang dimungkinkan oleh LifeKeeper dan DataKeeper, pengenalan utilitas ini memfasilitasi integrasi dengan infrastruktur TI yang mempertahankan kohesi dalam desain solusi.

Sebagai hasil dari pola desain yang digunakan, klaster yang dilindungi oleh SIOS Protection Suite (LifeKeeper dan/atau DataKeeper) membentuk elemen abstrak dan modular yang terintegrasi dengan mulus ke dalam desain dan solusi yang ada. LifeKeeper dan DataKeeper melakukan lebih dari sekadar menyederhanakan administrasi sistem tunggal atau masing-masing klaster; LifeKeeper dan DataKeeper bekerja dengan prinsip-prinsip yang berlaku dalam sebuah implementasi.

Pembuatan infrastruktur menjadi lebih sederhana dan efisien karena penggunaan SIOS Protection Suite memungkinkan metode yang mudah untuk memahami peran sistem dalam desain, sekaligus menyediakan metode sederhana untuk mengimplementasikan Ketersediaan Tinggi dan Pemulihan Bencana. Administrator dapat menggunakan LifeKeeper dan DataKeeper sebagai alat untuk meningkatkan kemampuan mereka dalam memahami, mengoperasikan, dan meningkatkan solusi untuk tahun-tahun mendatang.

Lihat bagaimana ketersediaan tinggi dapat mendukung desain infrastruktur Anda—tanpa menambah kerumitan.Minta demo hari ini!

Penulis: Philip Merry, CX Software Engineer di SIOS

Direproduksi dengan izin dariSIOS

Peran Penting Lingkungan QA dan Produksi dalam Ketersediaan Tinggi

Peran Penting Lingkungan QA dan Produksi dalam Ketersediaan Tinggi

Untuk tim TI yang mengelola aplikasi modern danMempertahankan ketersediaan yang tinggiMeskipun meluncurkan pembaruan bisa menjadi tantangan, bagian integral untuk mencapai keandalan adalah pemisahan lingkungan Jaminan Kualitas (QA) dan produksi. Meskipun mungkin tampak seperti praktik sepele, hal ini penting untuk mendeteksi potensi masalah dan menanamkan kepercayaan pada tugas pemeliharaan.

Lingkungan QA sebagai Tempat Pengujian untuk Ketersediaan Tinggi

Lingkungan QA berfungsi sebagai replika dari lingkungan produksi. Ini menyediakan lingkungan uji coba (sandbox) tempat fitur baru, perubahan konfigurasi, dan patch dapat diuji secara menyeluruh. Selain pengujian fungsional, lingkungan QA memungkinkan validasi proses, pengukuran kinerja, pengujian beban, dan validasi keamanan.

Ini adalah aktivitas penting untuk mengidentifikasi hambatan, kerentanan, atau masalah integrasi sebelum hal tersebut berdampak pada pengguna akhir atau membahayakan lingkungan Anda. Untuk sistem terdistribusi atauarsitektur awanLingkungan QA dapat membantu mensimulasikan latensi jaringan, penundaan replikasi basis data, dan kasus-kasus ekstrem operasional lainnya yang dapat mengganggu operasional bisnis jika tidak diuji.

Lingkungan Produksi dan Pengalaman Pengguna Akhir

Lingkungan produksi adalah tempat pengguna akhir bergantung pada sistem untuk berkinerja secara konsisten. Setiap waktu henti atau kegagalan yang tidak direncanakan dapat memiliki konsekuensi bisnis langsung, mulai dari hilangnya pendapatan hingga kerusakan reputasi.

Dengan memisahkan lingkungan produksi dari pengembangan dan pengujian yang sedang berlangsung, tim TI dapat memastikan stabilitas operasional. Lingkungan produksi yang dikonfigurasi dengan benar harus mencakup hal-hal berikut.strategi redundansi, mekanisme failover, dan alat pemantauan yang telah divalidasi melalui pengujian di lingkungan QA sebelum diterapkan.

Transisi yang Lancar Melalui Alur Implementasi yang Terstruktur

Ketersediaan tinggi tidak hanya tentang menjaga sistem tetap berjalan. Ini juga dapat mencakup membuat pembaruan dapat diprediksi. Lingkungan QA dapat mendukung alur kerja penerapan yang terstruktur, memungkinkan berbagai strategi seperti peluncuran bertahap dan rilis biru-hijau. Prosedur pengembalian (rollback), yang telah divalidasi sebelumnya di QA, memungkinkan tim untuk pulih dengan cepat jika masalah tak terduga muncul. Pendekatan terstruktur membuat pembaruan dapat diprediksi dan membantu menjaga kepercayaan pelanggan.

Manfaat Operasional dari Pemisahan Lingkungan QA dan Produksi

Memiliki lingkungan QA dan produksi yang terpisah juga dapat mendukung kepatuhan, kesiapan audit, dan koordinasi antar tim. Batasan yang jelas antara pengujian dan sistem yang berjalan dapat membantu tim operasional dan pengembangan berkolaborasi secara efisien. Hal ini juga membantu menyediakan kerangka kerja yang dapat diulang untuk pemantauan, pemecahan masalah, danperencanaan pemulihan bencana.

Lingkungan QA dan Produksi dalam Strategi Ketersediaan Tinggi

Lingkungan QA dan produksi memainkan peran penting dalam menjaga agar sistem berjalan lancar. Dengan memisahkan lingkungan, melakukan pengujian secara menyeluruh, dan mengelola penyebaran dengan hati-hati, tim TI dapat mengurangi waktu henti, mempertahankan ketersediaan tinggi, dan membuat transisi antar pembaruan menjadi lancar. Praktik-praktik ini membantu memastikan sistem tetap andal dan tangguh seiring perkembangannya.

Siap meningkatkan ketersediaan tinggi di seluruh lingkungan QA dan produksi?Minta demountuk melihat bagaimana SIOS membantu tim menerapkan pembaruan dengan percaya diri dan menjaga agar sistem penting tetap berjalan.

Penulis: Tristan Allen, Associate Customer Experience Software Engineer di SIOS Technology

Diterbitkan ulang dengan izin dari SIOS .

Bahaya Mematikan, Menghidupkan Kembali: Berpikir dalam Ketersediaan Tinggi

Bahaya Mematikan, Menghidupkan Kembali: Berpikir dalam Ketersediaan Tinggi

“Matikan, lalu hidupkan kembali.” Siapa pun yang pernah berpengalaman memecahkan masalah komputer pasti pernah mendengar saran ini. Saran ini terkenal sebagai solusi teknologi yang paling umum, dan mampu mengubah siapa pun menjadi ahli pemecah masalah TI. Masalahnya adalah, ini sebenarnya bukanlah solusi sebenarnya; ini hanya kebetulan menyelesaikan sebagian besar masalah. Dengan mematikan dan menghidupkannya kembali, kita dengan cepat dapat kembali beroperasi, tetapi kita tidak pernah benar-benar mengetahui apa masalah sebenarnya sejak awal.

Mengapa “Mematikan dan Menghidupkan Kembali” Berisiko dalam Sistem Ketersediaan Tinggi

Selain itu, dalam dunia ketersediaan tinggi, “mematikannya” bisa menjadi masalah besar. Bahkan hanya beberapa menit sajawaktu hentiHal ini bisa menjadi masalah besar bagi perusahaan yang harus memastikan infrastruktur kritis mereka tetap beroperasi. Karena itu, sebagai tim dukungan teknis di SIOS, kami jarang memberikan saran teknis yang terkenal buruk ini, tetapi kami memiliki versi kami sendiri.

Banyak yang telah menghubungi dukungan teknis di SIOS untukWindows DataKeeperJika mengalami masalah mirroring, Anda mungkin akan disarankan untuk menjalankan perintah “cleanupmirror.” Dalam situasi yang tepat, perintah ini sangat bagus untuk membantu seseorang mengatasi masalah besar dengan cepat. Perintah ini pada dasarnya menghapus konfigurasi mirror dan semua sisa-sisa yang mungkin ada, sehingga kita dapat membuat mirror baru, bebas dari masalah apa pun yang sebelumnya mengganggunya. Perlu dicatat bahwa ini sebenarnya tidak menghapus data apa pun, hanya replikasi antar sistem.

Perintah ini tidak memerlukan waktu henti, tetapi berarti sistem tidak akan memiliki ketersediaan tinggi hingga proses sinkronisasi ulang mirror selesai. Ini adalah salah satu langkah pemecahan masalah andalan kami dalam dukungan teknis, tetapi seperti “matikan, lalu hidupkan kembali,” terkadang hal ini dapat menyembunyikan masalah mendasar yang lebih serius, dan terkadang bisa berlebihan.

Hari ini, saya ingin membahas salah satu kasus di mana menjalankan cleanupmirror berhasil mengatasi masalah mendesak bagi pelanggan, tetapi hampir membuat kami melewatkan masalah yang cukup serius, yang dapat memengaruhi banyak pelanggan, namun memiliki solusi dan perbaikan yang sangat mudah.

Masalah Mirroring DataKeeper di Dunia Nyata Selama Migrasi

Ketika tim dukungan bergabung, pelanggan sudah cukup lama mencoba mengatasi masalah ini, dan mereka mulai panik. Mereka sedang melakukan upaya terakhir mereka.peralihanPengujian sedang dilakukan sebagai bagian dari migrasi mereka ketika mirroring DataKeeper mulai mengalami masalah. Pada titik ini, infrastruktur penting mereka mengalami gangguan, dan mereka khawatir hal itu akan mulai memengaruhi bisnis mereka. Ini adalah situasi yang sangat menegangkan, tetapi untungnya, para insinyur dukungan di sini melakukan pekerjaan yang sangat baik. Mereka menyeimbangkan tekanan, ketergesaan, dan kebutuhan untuk menemukan solusi yang baik, dan menjalankan perintah “cleanupmirror” yang sudah teruji dan terbukti, diikuti dengan pembuatan ulang mirror agar berfungsi dengan baik. Mereka menyelamatkan pelanggan dari kesulitan, dan semua orang melanjutkan pekerjaan. Untungnya, mereka juga meminta pelanggan untuk mengirimkan log, “sebagai tindakan pencegahan.”

Catatan dalam kasus ini agak membingungkan. Catatan tersebut menunjukkan bahwasebuah volume telah diubah ukurannyaNamun, pelanggan mengklaim bahwa mereka tidak melakukan aktivitas pengubahan ukuran apa pun selama panggilan tersebut. Terkadang pelanggan lupa menyampaikan informasi penting, jadi kami mengira mungkin mereka lupa menyebutkan detail tersebut dalam panggilan, tetapi pengubahan ukuran tersebut tidak masuk akal. Perubahan ukurannya sangat kecil, dan terjadi pada semua volume secara bersamaan dengan peralihan pertama. Tidak masuk akal bagi pelanggan untuk mengubah ukuran terabyte drive besar mereka dengan mengurangi kurang dari satu gigabyte sekaligus, tepat pada saat yang bersamaan dengan peralihan pertama, jadi kami menyelidiki lebih dalam. Ternyata drive target sedikit lebih besar daripada drive sumber, dan ada masalah pada produk kami terkait cara penanganan ukuran drive yang tidak sesuai.

Mengidentifikasi Akar Penyebab Mencegah Terulangnya Waktu Henti

Setelah kami menemukan solusinya, kami menyadari bahwa yang dibutuhkan untuk menyelesaikan masalah ini hanyalah melanjutkan mirroring. Ini adalah operasi umum, cepat, dan mudah yang hanya membutuhkan beberapa detik untuk memperbaiki masalah sepenuhnya. Tidak perlu sinkronisasi ulang berhari-hari sebelum kami kembali memiliki ketersediaan tinggi. Selain itu, setelah kami menemukan masalah ini, perbaikannya sangat cepat dan mudah untuk diimplementasikan pada versi produk berikutnya.

Ternyata pelanggan tersebut memiliki skenario migrasi yang unik, yang mengharuskan mereka untuk membuat target sedikit lebih besar, karena menyamakan ukurannya tidak mungkin dilakukan. Mereka masih memiliki beberapa sistem yang belum dimigrasikan, dan jika kami hanya menyelesaikan kasus ini dengan “cleanupmirror,” mereka akan menghadapi masalah ini setiap kali. Karena kami menemukan akar penyebabnya, kami dapat memberi mereka solusi cepat dan mudah, dan bahkan tindakan pencegahan yang lebih cepat yang dapat mereka lakukan sebelum menjalankan peralihan pertama. Kami juga dapat mempublikasikan solusi, sehingga pelanggan berikutnya yang mengalami masalah ini dapat menyelesaikannya dalam hitungan menit.

Mengapa Analisis Akar Penyebab Penting dalam Ketersediaan Tinggi?

Jadi, apa masalah besar dengan “matikan, lalu hidupkan kembali”? Itu menyembunyikan akar permasalahan. Jadi, apakah itu berarti Anda tidak boleh menggunakannya sama sekali? Itu masih merupakan salah satu saran teknologi terbaik yang ada. Seringkali, Anda sebenarnya tidak perlu tahu apa akar permasalahannya, dan mematikan lalu menghidupkannya kembali akan membantu Anda keluar dari masalah dengan sangat cepat.

Hal terpenting bagi seorang profesional TI adalah, ketika Anda tidak perlu segera keluar dari situasi sulit dan memiliki waktu luang untuk menyelidiki terlebih dahulu, Anda harus melakukannya. Jika tidak, Anda harus kembali lagi nanti dan melihat log untuk mencoba mencari tahu apa yang terjadi.

Jadi, silakan matikan dan hidupkan kembali sesuka hati Anda. Jadilah pesulap yang memecahkan satu masalah dalam hitungan menit, dan buat semua orang bertanya-tanya bagaimana Anda melakukannya. Tapi… sesekali… luangkan waktu untuk kembali dan mencari tahu mengapa Anda perlu mematikan dan menghidupkannya kembali… dan pertimbangkan kemungkinan bahwa mungkin ada solusi yang lebih mudah.

Untuk mempelajari lebih lanjut tentang bagaimana SIOS DataKeeper dan solusi ketersediaan tinggi dapat membantu Anda menghindari masalah tersembunyi seperti ini,minta demodari tim kami hari ini.

Penulis: Carter Chandler, CX Associate, Insinyur Perangkat Lunak di SIOS Technology

Direproduksi dengan izin dariSIOS

Kemitraan SIOS

Kemitraan SIOS

Kemitraan SIOSmemainkan peran kunci dalam memungkinkan ketersediaan tinggi, ketahanan cloud, dan solusi infrastruktur terintegrasi.

Dalam podcast iniDalam podcast ini, Harry dan Kelly mengajak pendengar untuk menyelami ekosistem mitra SIOS, mulai dari aliansi cloud dengan Microsoft, AWS, dan Google Cloud hingga kolaborasi yang bermakna dengan ISV strategis seperti Exabeam, Milestone, dan Cimcor. Mereka membahas bagaimana SIOS merekrut dan mendukung mitra baru, berbagi pelajaran yang dipetik dari pengalaman bertahun-tahun membangun integrasi yang sukses, dan menyoroti ke mana arah inovasi yang didorong oleh mitra selanjutnya—termasuk peluang di bidang AI, cloud hybrid, dan edge computing.

Podcast ini diakhiri dengan saran praktis dan kisah sukses favorit yang menunjukkan dampak bisnis dari kemitraan teknologi yang kuat.

Direproduksi dengan izin dariSIOS