CMG dampak ulasan konferensi 2016

Artikel ini didedikasikan untuk konferensi, yang diadakan hampir 2 tahun yang lalu. Mengapa menulis tentang acara yang sudah berlangsung lama? Pertama, menurut saya, tidak banyak orang tahu tentang konferensi ini. Kedua, kesan pribadi saya tentang dia begitu kuat bahkan setelah dua tahun sehingga saya tidak bisa tidak membagikannya. Ketiga, saya benar-benar ingin menulis, tetapi tidak begitu jelas bagaimana melakukannya, karena saya belum pernah menulis ulasan sebelumnya, ini adalah upaya ketiga saya untuk menulis tentang konferensi ini. Dan, tentu saja, saya ingin mengucapkan terima kasih kepada perusahaan Distillery, di mana saya bekerja pada waktu itu, dan penyelia saya Sergei Meshcheryakov atas kesempatan untuk menghadiri konferensi ini.



Konferensi dampak CMG internasional diadakan setiap tahun oleh Asosiasi Spesialis Amerika di Bidang Peningkatan Kinerja Sistem TI. Konferensi CMG tahunan telah diadakan sejak 1980.

Konferensi ini didedikasikan untuk rekayasa kinerja dan perencanaan kapasitas. Penyelenggara, pembicara, dan peserta konferensi adalah spesialis berkualifikasi tinggi di bidang TI atau di bidang perencanaan kapasitas, banyak di antaranya mulai bekerja pada mainframe, kemudian pergi ke sistem terdistribusi, dan saat ini terus bekerja di perusahaan-perusahaan terkemuka di industri. Kualifikasi banyak dari mereka luar biasa. Ada perusahaan atau perwakilan mereka di konferensi yang terkait dengan pemantauan atau pengujian kinerja Dynatrace, NewRelic, Soasta, Jmeter, BMC, Moviri, BezNext dan banyak lainnya.

Pada konferensi tersebut, 120 laporan disajikan dari lebih dari 15 negara di dunia, terutama Amerika Serikat, Kanada, dan negara-negara Eropa. Itu dilakukan selama lima hari dari 7 hingga 11 November 2016. Cara operasi adalah sebagai berikut: laporan pada sesi pleno dimulai dari jam 8 pagi dan dilanjutkan dengan laporan bagian di 8 kamar sampai jam 19.00 malam dengan istirahat makan siang singkat di area sore. Setiap hari kerja konferensi berakhir dengan prasmanan umum, di mana dimungkinkan untuk berkomunikasi secara pribadi dengan semua pembicara dan mendiskusikan laporan yang disajikan. Agak sulit untuk menentukan pilihan mana yang akan dihadiri, karena dalam sesi paralel laporan yang menarik secara bersamaan berada di ruangan yang berbeda.

Dalam artikel ini saya akan menjelaskan secara singkat laporan yang paling saya sukai.

Asosiasi Spesialis Amerika dalam Meningkatkan Kinerja Sistem TI Kelompok Manajemen Komputer pada 1974 menetapkan Abraham Michelson Award tahunan atas kontribusi profesionalnya dalam menilai kinerja sistem. Penghargaan ini secara tradisional diberikan pada konferensi dampak CMG.

Pembukaan konferensi dan presentasi Michelson Award AA

Konferensi dibuka dengan Andrei Bondi AA Michelson Award, seorang konsultan independen, penulis Yayasan Rekayasa Perangkat Lunak dan Kinerja Sistem: Proses, Pemodelan Kinerja, Persyaratan, Pengujian, Skalabilitas, dan Praktik.
Sesi pleno pertama dimulai dengan laporan oleh Andre Bondi. Gagasan utama dari laporan ini adalah bahwa penyetelan tidak akan pernah mengarah pada peningkatan kinerja pada waktu-waktu tertentu. Menurut penulis laporan tersebut, peningkatan terbesar dalam produktivitas dapat diperoleh dengan menghilangkan kesalahan arsitektur dalam sistem. Saya pikir banyak dari Anda tahu ini dari pengalaman pribadi. Sepanjang karier saya, saya sampai pada kesimpulan yang sama. Misalnya, pindah dari satu sistem yang tampaknya lebih produktif ke sistem opensource yang lebih sederhana dapat memberikan peningkatan kinerja jika, selama transfer, tim menghilangkan kesalahan arsitektural dari versi sistem sebelumnya.

Mencapai Skalabilitas dan Kinerja> 1M Pengguna Bersamaan di Saatnya
Lukas Sliwka, Grindr

Presentasi menarik berikutnya bagi saya adalah laporan mereka. Direktur Grindr Lucas Cream. Grindr adalah aplikasi kencan online. Lukash berbicara secara bersamaan tentang transformasi perusahaan, dan budaya pengembangan (mereka beralih ke scrum), dan tentang transformasi teknis sistem. Grindr memiliki lebih dari 2,5 juta pengguna, di mana 1 juta di antaranya aktif. Pengguna utama sebelum konversi adalah di AS dan Kanada, saat mereka pindah dari AS, jumlah pengguna menurun.



Server dan gudang data juga berlokasi terutama di AS. Selain itu, aplikasi telah pindah ke server paling kuat di hosting, dan perusahaan dihadapkan dengan masalah akut optimasi dan penskalaan. Masalah optimasi dan penskalaan diselesaikan secara radikal - tim sepenuhnya menulis ulang seluruh proyek dari Ruby on Rails ke Scala, butuh enam bulan. Scala dipilih karena dua alasan: pertama, memungkinkan untuk menulis kode bersih dengan kinerja yang baik; kedua, pengembang Java lebih tersedia untuk disewa, tidak seperti pengembang Node.js yang mahal dan semuanya bekerja di Facebook.

Pengalaman menarik dari Grindr membuktikan bahwa untuk pengembangan yang sukses, terkadang Anda membutuhkan arsitektur baru. Selanjutnya, dilakukan analisis mengenai durasi respons dalam konteks masing-masing negara, dan ternyata semakin lama respons, semakin sedikit pengguna di negara ini. Tim pengembangan telah mengoptimalkan waktu respons, mengurangi secara signifikan menggunakan CDN, dan mendistribusikan data warehouse pada server cloud dengan pusat-pusat di Eropa, Asia dan Amerika Latin. Setelah masalah kinerja diselesaikan, jumlah pengguna aplikasi telah meningkat di seluruh dunia. Contoh ini membuktikan hubungan langsung antara waktu respons singkat dan jumlah pengguna.

Bagian kedua dari laporan ini dikhususkan untuk manajemen tim. Grindr bekerja di Scrum. Pemisahan tim dilakukan oleh produk, yaitu, masing-masing tim bertanggung jawab penuh atas beberapa layanan atau produk untuk pengguna, dan untuk nilai bisnis yang diterima pengguna. Perusahaan adalah perusahaan yang digerakkan oleh metrik, dan setiap tim memiliki metrik dan KPI sendiri yang harus mereka capai. Manajemen tingkat menengah sama sekali tidak ada. Perusahaan memiliki struktur yang rata, dan tim memutuskan apa yang perlu dilakukan dan bagaimana mencapai tujuannya. Laporan Lukash ada di YouTube . Wawancara Lucas tersedia di sini .

Apakah Kapasitas Anda Tersedia?
Igor Trubin, Bank Capital One

Sangat menarik bahwa penulis memulai laporannya dengan informasi bahwa bank Capital One memutuskan untuk menjadi perusahaan yang terbuka secara informasi. Sudah diketahui bahwa bank biasanya tidak berbicara tentang teknologi dan proses. Digunakan dalam pekerjaan mereka, mengingat informasi ini rahasia. Namun, di dunia modern, untuk bersaing untuk spesialis terkemuka dan bakat mereka, yang biasanya bekerja di Google dan Facebook, bank harus lebih terbuka.

Laporan ini dikhususkan untuk menilai kombinasi ketersediaan sistem dan margin kinerjanya. Karena tidak ada yang membutuhkan bandwidth yang tidak dapat digunakan.

Igor menjelaskan bentuk spesifik tentang bagaimana Anda dapat mengukur kapasitas dan ketersediaannya. Dia memiliki metrik seperti waktu rata-rata antara jatuh, waktu pemulihan rata-rata, waktu henti selama setahun, dan lainnya. Igor memberikan formula yang dengannya Anda dapat menghitung ketersediaan seluruh infrastruktur Anda untuk pengguna. Anda dapat melihat laporannya lebih terinci.

Perencanaan Kapasitas Pengalaman Digital
Amy Spellmann dan Richard Gimark

Merencanakan pembicaraan untuk metrik Bisnis IoT, metrik TI, dan metrik Fasilitas.

Sebuah laporan tentang fakta bahwa banyak infrastruktur sekarang bekerja mendekati batas bandwidth mereka, dan apa yang akan terjadi ketika IoT akan bekerja di mana-mana. Bagi saya, yang paling menarik dalam laporan itu adalah skalanya. Artinya, ada profesional yang merencanakan situs, untuk organisasi, dan ini adalah seluruh industri. Seberapa sering kita mencapai visi berskala besar seperti itu?

Jaminan kinerja perusahaan berdasarkan analitik BigData
Boris Zibitsker

Boris berbicara tentang BigData dan pendekatan untuk bekerja dengan data besar. Dia mengidentifikasi tahapan kerja dengan data berikut. Analisis prediktif, sebagai bisnis harus membuat keputusan berdasarkan data saat ini. Waktu adalah uang dan tidak ada yang berubah selama bertahun-tahun, kecuali waktu yang telah menjadi lebih mahal sekarang. Informasi itu mahal jika relevan.
Bekerja dengan kelompok data besar memungkinkan Anda memberikan analisis yang diperlukan tepat waktu. Boris kemudian menjelaskan langkah-langkahnya. Dua pendekatan utama adalah melakukan analisis data real-time dalam aliran atau untuk mengumpulkan dari dalam DataLake.

Laporan ini menjelaskan pendekatan menggunakan pemrosesan data besar dan algoritma pembelajaran mesin untuk melakukan RCA jika terjadi kegagalan, serta membangun prakiraan berdasarkan laporan tersebut tentang perilaku sistem selanjutnya.

Poin penting adalah memverifikasi keandalan hasil, dengan membandingkan perilaku aktual dengan yang diprediksi.

Top 10 Cacat Kinerja, Jutaan Biaya Organisasi Online
Craig Hyde, Rigor dan Rigor

Craig menggambarkan 10 kesalahan paling mahal yang mempengaruhi kinerja situs. Craig mengutip angka-angka yang, rata-rata, sebuah perusahaan kehilangan $ 102 juta potensi untuk 1 detik menunggu pengguna. Menarik, ya? Perusahaan melakukan analisis terhadap sekitar 500 situs web dan menyusun 10 masalah utama teratas yang menyebabkan kinerja buruk. Rekomendasi Craig tentang penggunaan cache, CDN, pengaturan resolusi gambar yang benar, menggunakan kompresi. Tetapi yang utama adalah menguji apa yang terjadi, ternyata, banyak orang berpikir bahwa mereka menggunakan cache, tetapi sekitar 70% dari konten mungkin tidak di-cache karena pengaturan yang salah. Craig merekomendasikan pengaturan garis dasar kinerja dan berpegang teguh pada itu, menetapkan tujuan kinerja untuk mencapai, menguji dan mengoptimalkan kemacetan. Alat uji, uji halaman web, analisis google, kecepatan halaman, laporan bebas kekakuan. Yang paling menyenangkan bagi saya adalah gambar di situs dalam ekstensi besar, sedangkan ukurannya tidak memungkinkan saya untuk mengevaluasi ini, jadi penurunan resolusi tidak menyebabkan penurunan kualitas.

Saya tidak dapat menemukan slide Craig, tetapi di sini ada laporan tentang topik yang sama oleh salah satu karyawan perusahaan.

Bisnis berisiko
Jeff Buzen

Beberapa kata tentang Jeff - ia adalah seorang guru di Harvard, penulis 3 buku, yang pertama diterbitkan pada 71, dan yang terakhir pada 2015 - Memikirkan Kembali Keacakan: Yayasan Baru untuk Pemodelan Stokastik, artikel wiki , Wawancara dengan Jeff .

Laporan kinerja pemodelan dan perkiraan. Jeff menjelaskan risiko yang muncul saat memodelkan risiko sistem - model, risiko parameter beban sistem, risiko prakiraan, risiko aplikasi, risiko penggunaan - di tempat kerja. Jeff menjelaskan secara terperinci semua risiko yang mungkin muncul saat memodelkan sistem dan berupaya memprediksi berapa banyak sumber daya yang akan dibutuhkan dan ketersediaan sistem seperti apa yang dibutuhkan. Opsi karena tidak perlu menulis SLA - 90% dari permintaan dieksekusi dalam 0,5 detik. Kurang berisiko - panjang antrian kurang dari 33x90% dari waktu. Bukunya tentang itu. Peramalan yang kami gunakan dari matematika klasik tidak selalu memberikan hasil yang benar, meskipun rumusnya mungkin benar. Prediksi sangat tergantung pada asumsi model. Lebih baik menggunakan ramalan berdasarkan analisis alternatif (AoA, Analisis Alternatif).

Saya duduk dan berpikir - seberapa jauh ini dari pengalaman saya - oh, kita masih memiliki margin produktivitas dalam 2 kali, apa? Bagaimana Anda mengetahuinya? Nah, ada puncak dan antrian sudah terakumulasi dalam sistem, mari kita ambil server yang lebih besar. Apa yang dikatakan Nah, apa barisnya? Nah, sebelum kita mulai menggunakannya, sistemnya runtuh. Berikut ini adalah pendekatan perencanaan kinerja yang dimulai dengan model sistem - beberapa planet lain.

Bagaimana cara mendapatkan nilai dari BigData?
Renato Bonomini, Stefano Doni, Moviri

Berikutnya adalah lokakarya dari Moviri . Moviri adalah perusahaan yang didirikan oleh seorang profesor di Universitas Politeknik Milan, dengan kantor di Milan dan Boston, yang mengkhususkan diri dalam analisis kinerja dan throughput. Tentang betapa pentingnya tidak hanya mengumpulkan banyak data, tetapi juga mendapatkan manfaat darinya. Stack Yarn, HDFS, Pig, Hive, Spark, Zookeeper, Cassandra, Cloudera, Kubernetes. Laporan itu menunjukkan betapa jauh lebih nyaman untuk bekerja dengan mengubah kinerja dengan sistem yang berjalan dalam wadah.

Moviri mengundang saya ke kantor saya, yang saya manfaatkan, karena sekitar sebulan kemudian saya pergi ke Italia. Senang bertemu dengan Stefano Doni dan berkenalan dengan Luca Forni, melihat kantor dan berbicara tentang segala sesuatu yang berkaitan dengan analisis kinerja, dimulai dengan analisis kinerja dan berakhir dengan masalah yang dihadapi konsultan ketika berkomunikasi dengan tim pelanggan.

Blog Moviri .

Kinerja atau Kapasitas? Pendekatan berbeda untuk tugas yang berbeda
Alexander Gilgur, Facebook

Laporan ini akan bermanfaat bagi mereka yang terlibat dalam memprediksi kinerja dan perencanaan bandwidth. Alexander memberikan contoh dan pendekatan yang harus digunakan untuk masing-masing kasus. Secara umum, meskipun konsep kapasitas dan kinerja dekat, metode yang berbeda harus digunakan untuk prakiraan, dengan penekanan pada tujuan akhir pekerjaan. Kenapa kita melakukan ini? Kami ingin memahami berapa banyak peralatan yang kami butuhkan dan bandwidth apa yang ingin kami sediakan atau kami ingin memprediksi kinerja sistem.

Di sini Anda dapat membaca artikel oleh Alexander .
Slide .

Cara memulai ketika Anda tidak tahu harus mulai dari mana.
Justin Martin, Cerner

Tentang mengapa secara umum perlu dilakukan pemantauan kinerja. Tetapi kenyataannya adalah! Banyak yang hidup tanpa pengawasan dan semuanya tampak baik-baik saja dengan mereka. Memang banyak yang tidak membutuhkannya. Sampai mereka menerbitkan artikel tentang situs mereka yang luar biasa di hub, dan orang-orang tidak pergi ke mereka untuk melihat apa yang ada di sana. Atau sampai sesuatu yang lain tidak mengarah pada banyak, banyak pengguna.



Dalam laporan itu, Justin mengatakan dengan sederhana apa yang bisa dilakukan untuk memulai. Manajemen kapasitas dalam 90 hari

Langkah-langkah

1. Tentukan jam sibuk untuk sistem Anda
2. Periksa batas kinerja proyek Anda (saat ketika sistem sudah berhenti memproses permintaan dan kinerja mulai menurun)
3. Mengurangi Kerugian Produktivitas
4. Seimbangkan kebutuhan - mungkin Anda dapat mentransfer beberapa dari jam sibuk ke waktu yang kurang sibuk.

Linkedin Justin . Slide dapat dilihat pada artikel tentang konferensi, yang akan saya terbitkan di bagian akhir.

Penyeimbangan beban dinamis dan Pengiriman Layanan Berkelanjutan dalam Infrastruktur Awan Besar
Yuri Ardulov, RingCentral

Yuri menjelaskan transisi RingCentral dari monolith, dengan kode lawas ke layanan microser. Masalah dengan kode monolitik adalah bahwa sulit untuk mengubah konfigurasi, tidak mungkin untuk melakukan pengiriman terus menerus, kesulitan dalam mencapai indikator ketersediaan yang diperlukan, tidak ada cara untuk melakukan pengujian A \ B, kemampuan untuk menerapkan fungsi baru hanya untuk beberapa pengguna. Sistem dirancang ulang dan wadah dan layanan microser digunakan dalam desain baru, memungkinkan untuk mengubah ukuran sistem secara online, kemampuan untuk mengubah versi layanan tanpa mengubah konfigurasi. Dalam arsitektur microservice, lapisan perutean aplikasi, lapisan penyeimbang, lapisan layanan (tidak menyimpan status) dialokasikan. Setelah membuat perubahan Ops, tim dapat melakukan pengiriman terus menerus dengan cepat, ketersediaan sistem meningkat dari 4 sembilan menjadi 99,998. Waktu yang diperlukan untuk meningkatkan sistem dan menggunakan server baru dikurangi menjadi 4 jam.

Menghindari biaya, keterlambatan, dan rilis yang gagal dengan Lifecycle Virtualization
Todd DeCapua, layanan merek digital CSC

Laporan Tod berfokus pada bagaimana mengurangi masalah rilis dan ide utamanya adalah bahwa ketika menguji suatu program, penting untuk mempertimbangkan seluruh siklus hidup program.

4 komponen utama:

1. Pengguna - virtualisasi pengguna yang mensimulasikan perilaku pengguna sistem Anda yang sebenarnya.
2. Layanan - harus ada virtualisasi layanan sehingga Anda dapat memeriksa operasi seluruh proses dari awal hingga selesai.
3. Jaringan - meniru kondisi operasi jaringan.
4. Data - virtualisasi data dengan penjualan untuk mensimulasikan panggilan aplikasi yang mendekati apa yang akan terjadi dalam kenyataan.

Berdasarkan pengalaman saya, sebagian besar kesalahan selama pemasangan adalah karena fakta bahwa hanya sedikit orang yang memenuhi keempat kondisi, dan prod selalu memiliki sesuatu yang tidak ada yang diharapkan untuk melihat, dan ini merusak rilis. Sangat penting untuk menggunakan berbagai kasus penggunaan dengan penjualan sesuai dengan data dan perilaku pengguna.

Berikut ini adalah contoh dari presentasi Tod:





Tod - Penulis buku tentang optimasi kinerja, tes kinerja dan interpretasinya.

Buku ini menceritakan betapa pentingnya budaya pengujian kinerja dalam suatu organisasi, bagaimana hal itu bisa dibawa jika tidak ada yang melakukannya sekarang. Beberapa contoh dari praktik diberikan dengan deskripsi tugas yang dihadapi tim, pilihan untuk menyelesaikannya, pendekatan mana yang dipilih tim dan apa konsekuensinya dalam sistem nyata. Menurut pendapat saya, kisah-kisah ini sering mengenai betapa sulitnya untuk memprediksi perilaku pengguna akhir, dan betapa pentingnya membuat kelompok fokus kecil dari jumlah pengguna yang terbatas dan melihat bagaimana perkiraan Anda cocok dengan perilaku kelompok fokus.

Menerapkan Metrics-Driven DevOps: Mengapa dan Bagaimana!
Andreas Grabner, Dynatrace

Laporan oleh Andreas Grabner tentang praktik DevOps di berbagai perusahaan dan mengapa short2market itu penting. Andreas menggunakan metafora yang sangat menarik tentang fotografi. Banyak orang mengingat foto film - Anda mengambil foto, mengembangkan, mencetak, dan melihat bahwa itu tidak berhasil, tetapi Anda tidak memiliki kesempatan untuk mengambil kembali foto tersebut, karena Anda sudah berada di saat yang salah.

Sekarang semuanya berbeda - Anda mengambil foto, mempostingnya di Instagram dan segera mendapatkan umpan balik dan Anda dapat menyelesaikan sesuatu dari apa yang diminta pelanggan Anda. Anda masih dalam momen dan mendapatkan reaksi secara real time.

Sekarang, kembali ke perangkat lunak - seperti sebelumnya - fitur perangkat lunak baru direncanakan, diimplementasikan, diuji dan dibuat, misalnya, 1 rilis per tahun. Dan mereka mengerti bahwa fungsi yang menghabiskan banyak uang dan usaha dibutuhkan oleh dua dari jutaan pengguna. Apakah ini terjadi pada Anda?

Bagaimana sekarang? Agile dan kemampuan untuk membuat rilis setidaknya setiap hari, seperti yang dilakukan Facebook, adalah kemampuan untuk segera menilai seberapa banyak fungsi ini diminati oleh pengguna, apakah itu harus ditimbang dengan riff, atau lebih baik membuangnya segera dan tidak membuang waktu dan energi.

Saya sangat merekomendasikan laporan kepada bisnis yang mencoba menjelaskan kepada timnya mengapa mereka membutuhkan Scrum dan Agile! Sekarang banyak perusahaan perusahaan terry dengan rilis 3 kali setahun mencoba untuk menjadi lebih cepat, lebih tipis dan lebih keras.



Secara umum, laporan ini bukan tentang ini, tetapi tentang bagaimana membangun praktik DevOps, membuat rilis sering dan bagus. Ya itu terjadi. Penting untuk menggunakan metrik dan memantau situasi dengan aplikasi, memuat, membuat penyebaran yang tepat pada proses. Andreas adalah seorang penganjur kinerja dan dia memiliki beberapa laporan berguna tentang hal ini dengan slide yang tidak biasa dan menarik.
Ini adalah laporan oleh Andreas dengan slide yang sedikit berbeda.

Pengujian Kinerja dalam Konteks Baru
Eric Proegler, Soasta

Pada awal pembicaraan, Eric secara retrospektif menggambarkan bagaimana arsitektur sistem telah berubah sejak tahun 2000, bagaimana transisi ke cloud telah berubah atau seharusnya berubah, dan bagaimana sistem dirancang dengan kemungkinan penskalaan di cloud. Eric memberikan contoh dari praktik ketika salah satu perusahaan TV meluncurkan pemungutan suara dalam aplikasi seluler dan hanya selama acara, ketika pengguna harus memilih, sistem tidak dapat menahan beban dan tidak dapat diakses. Dengan budaya startup, sulit untuk memprediksi berapa banyak pengguna, mungkin 20 ribu direncanakan, dan aplikasi akan dengan cepat mencapai 50 ribu. Ada banyak aplikasi untuk menguji kinerja di cloud BlazeMeter (Jmeter), Selenium, Gatling, Grinder. Mereka gratis, tetapi memvisualisasikan hasilnya tidak terlalu nyaman.Oleh karena itu, disarankan untuk menggunakan alat visualisasi lain (Tableau) atau menggunakan database Anda sendiri untuk kemudian menganalisis apa yang terjadi. Saat menguji aplikasi web, penting untuk memastikan bahwa pengguna uji yang masuk terdistribusi secara geografis. Dianjurkan untuk melakukan tes kinerja kecil untuk setiap perakitan dan membandingkannya dengan hasil dasar.

Slide Eric dapat dilihat di slideshare.

Eric adalah penulis blog .

Selain laporan yang dipresentasikan di konferensi, beberapa diskusi juga diselenggarakan dalam bentuk “Meja Bundar”. Beberapa ahli mengutuk topik tersebut dalam format dialog aktif yang hidup dengan audiensi. Menurut pendapat saya, ini adalah format yang sangat menarik, karena para peserta konferensi dapat membagikan pengalaman mereka yang seringkali mengesankan, dan adalah mungkin untuk datang untuk berbicara dengan masing-masing ahli dan peserta, membahas masalah-masalah yang menarik.

Percakapan offtopic dan di belakang panggung

Bagian khusus dari kesan saya pada konferensi ini adalah komunikasi informal dengan pembicara dan peserta. Berkat format diskusi, makan malam, meja bundar, dan resepsi, Anda dapat bertemu orang-orang dari seluruh dunia dari berbagai perusahaan dan bertukar pengalaman. Cukup banyak komunikasi di dalam konferensi. Orang-orang sangat terbuka dan mau berbagi pengalaman.

Saya juga ingin menyebutkan Debbie Sheetz. Debbie bekerja di BMC dan memulai analisis kinerjanya pada mainframe. Kemudian dia beralih ke sistem terdistribusi. Pengalamannya dalam pemantauan sangat luas dan sangat menarik.

Saya juga beruntung mengobrol dengan Anush Najarian dari MathWorks, yang pengalamannya juga patut mendapat perhatian.

Sayangnya, jumlah laporan tidak memungkinkan untuk mengunjungi semuanya, dan laporan tidak disimpan, yaitu, tidak ada cara untuk meninjaunya di rumah. Panitia menggunakan artikel untuk memilih pembicara, dan artikel ini kemudian diteruskan ke peserta konferensi, tetapi tidak ada bahan dari pembicara yang diundang dalam koleksi.

Inilah artikel Anush tentang konferensi itu .

Dampak CMG adalah konferensi yang sangat berguna dan menarik dengan suasana berbagi pengalaman yang hebat, yang saya rekomendasikan hadir.