Server World of Tanks Keandalan

Topik hari ini - keandalan World of Tanks Server - agak licin. Keandalan dari permainan ini saling menguntungkan, oleh karena itu segala sesuatu harus dilakukan dengan cepat dan cepat dalam pengembangan game. Beban pada server besar, dan pengguna cenderung merusak sesuatu hanya karena ketertarikan. Levon Avakyan di RIT ++ mengatakan apa yang dilakukan Wargaming untuk memastikan keandalan.

Biasanya, ketika mereka berbicara tentang keandalan, pemantauan, pengujian stres dan sebagainya disebutkan setiap saat. Tidak ada yang supernatural dalam hal ini, dan laporan itu dikhususkan untuk momen-momen khusus Tank.

Tentang pembicara: Levon Avakyan bekerja untuk Wargaming sebagai Kepala Layanan dan Keandalan Game WoT dan menangani masalah keandalan server tank.

Hari ini saya akan berbicara tentang bagaimana kami melakukan ini, termasuk apa yang dimaksud dengan server World Of Tanks, terdiri dari apa, apa itu dibangun, sehingga Anda memahami subjek pembicaraan. Selanjutnya kita akan mempertimbangkan apa yang bisa salah di dalam server itu sendiri dan sekitarnya, karena permainannya sudah lebih dari server. Dan kami juga akan berbicara sedikit tentang prosesnya, karena banyak yang lupa bahwa proses produksi yang mapan adalah bagian dari keberhasilan tidak hanya dalam hal penghematan sumber daya (banyak praktik berasal dari produksi nyata), tetapi juga memengaruhi kualitas dan keandalan solusi.


Biasanya, ketika mereka berbicara tentang keandalan, pemantauan, pengujian stres, dan sebagainya disebutkan setiap saat. Saya tidak memasukkannya di sini karena saya pikir itu membosankan. Kami belum menemukan sesuatu yang supranatural dalam hal ini. Ya, kami juga memiliki sistem pemantauan, kami melakukan stress testing dengan stress test untuk meningkatkan keandalan sistem dan tahu di mana itu bisa jatuh. Tapi hari ini saya akan berbicara tentang apa yang lebih spesifik untuk tank.

Teknologi BigWorld

Ini adalah mesin backend, serta toolkit untuk membuat MMO.

Mesin BigWorld Server yang cukup lama ini (berasal dari akhir 90-an - awal 2000-an) adalah serangkaian proses berbeda yang mendukung permainan. Proses diluncurkan pada sebuah cluster, yang saling terhubung dalam jaringan mesin. Berinteraksi satu sama lain, proses menunjukkan kepada pengguna semacam mekanisme permainan.

Mesin itu disebut BigWorld, karena sangat bagus untuk membuat game di atasnya, di mana ada lapangan besar (ruang), di mana operasi militer (pertempuran) berlangsung. Untuk Tank, ini sangat cocok.

Dalam hal keandalan, fitur-fitur utama berikut diinvestasikan di BigWorld:

• Load balancing. Mesin mengalokasikan sumber daya, berusaha mencapai dua tujuan:
  
  1. gunakan sesedikit mungkin mesin;
  2. pada saat yang sama, jangan memuat aplikasi Anda sehingga bebannya melebihi batas tertentu.
• Skalabilitas. Kami menambahkan mobil ke cluster, meluncurkan proses di atasnya - yang berarti Anda dapat menghitung lebih banyak pertempuran dan menerima pemain.
  
• Ketersediaan tinggi. Jika, misalnya, satu mobil jatuh atau ada yang salah dengan salah satu proses permainan yang melayani permainan itu sendiri, tidak ada yang perlu dikhawatirkan - permainan tidak akan melihat, akan dipulihkan di tempat lain dan akan berfungsi.
• Pertahankan integritas dan konsistensi data. Ini adalah level kedua dari toleransi kesalahan. Jika ada beberapa cluster, seperti di Tanks, dan ada semacam bencana di pusat data atau di saluran utama, ini tidak berarti bahwa kami akan benar-benar kehilangan data permainan yang telah dimainkan orang tersebut. Kami akan pulih, konsistensi akan.

Proses-proses yang ada di sistem kami dan fungsinya

• CellApp adalah proses yang bertanggung jawab untuk memproses ruang permainan atau bagian darinya.
  

Seperti yang saya katakan, BigWorld bekerja dengan ruang-ruang tertentu yang kita bagi menjadi sel. Setiap sel khusus ruang permainan kami dihitung oleh aplikasi tertentu.

• CellAppMgr - proses yang mengoordinasikan kerja CellApp, memuat keseimbangan.
  

CellApp bisa banyak, karenanya, harus ada proses yang mengendalikan mereka.

• BaseApp mengelola entitas, mengisolasi klien dari bekerja dengan CellApp.

Salah satu hal mendasar dalam BigWorld adalah konsep entitas - misalnya, akun pemain. Segala sesuatu yang kita lakukan di medan perang, kita lakukan dengan entitas ini. CellApps menghitung fisika dan mekanika game, seperti menembak. BaseApp bekerja dengan entitas. Ini melayani akun, tangki, dll.

• ServiceApp adalah BaseApp khusus yang mengimplementasikan beberapa jenis layanan.

Ini adalah versi sederhana dari BaseApp, sebuah proses yang melakukan berbagai hal layanan. Misalnya, seseorang harus dapat membaca dari RabbitMQ. Ini bukan tentang entitas game, tetapi juga diperlukan.

• BaseAppMgr mengelola BaseApp dan ServiceApp, karena ada banyak juga.
• LoginApp membuat koneksi baru dari klien, dan juga proksi pengguna di BaseApp.
• DBApp mengimplementasikan antarmuka akses penyimpanan (database). Kami bekerja dengan Percona, tapi mungkin itu database lain.
• DBAppMgr mengoordinasikan pekerjaan DBApp.
• InterClusterMgr mengelola komunikasi antarkluster.
• Reviewer adalah inspektur proses yang dapat memulai kembali proses.
• Diperbaiki   - daemon yang berjalan pada setiap mesin di cluster untuk mengoordinasikan pekerjaannya. Ini memungkinkan semua manajer BaseApp untuk saling berkomunikasi.

Beginilah tampilan Tank dari dalam, jika sangat singkat:

• Klien terhubung melalui Internet, dapatkan di LoginApp.
• LoginApp mengizinkan mereka menggunakan DBApp dan mengeluarkan alamat dari BaseApp.
• Pelanggan lebih lanjut memainkannya.

Semua ini tersebar di banyak mesin, masing-masing memiliki BWMachineD, yang dapat mengelola semua ini, mengatur, dll.

World of Tanks Ecosystem

Apa yang ada di sekitar? Tampaknya ada server permainan dan pemain - memilih tank, pergi bermain. Namun, sayangnya (atau dengan gembira), gim ini berkembang, dan mekanisme gim "hanya menembak" tidak lagi cukup. Dengan demikian, server permainan mulai ditumbuhi berbagai layanan, beberapa di antaranya secara umum tidak mungkin dilakukan di dalam server, sementara kami mulai mengeluarkan yang lain secara khusus untuk meningkatkan kecepatan pengiriman konten ke pemain. Yaitu, lebih cepat untuk menulis layanan kecil dengan Python yang melakukan semacam permainan mekanik daripada melakukannya di dalam server pada semua BaseAPPs, mendukung cluster, dll.

Beberapa hal, misalnya, sistem pembayaran pada awalnya dikeluarkan. Kami menahan orang lain, karena Wargaming mengembangkan lebih dari satu permainan. Ini adalah trilogi: Tank, Pesawat, Kapal, dan ada Blitz dan rencana untuk permainan baru. Jika mereka berada di dalam BigWorld, maka mereka tidak dapat dengan mudah digunakan dalam produk lain.

Semuanya berjalan cukup cepat dan kacau, yang menghasilkan beberapa teknologi kebun binatang yang digunakan dalam ekosistem tangki kami.

Teknologi dan protokol utama:

1. Python 2.7, 3.5;

2. Erlang;

3. Scala;

4. JavaScript;

Kerangka kerja

5. Django;

6. Falcon;

7. asyncio;

Penyimpanan:

8. Postgres;

9. Percona.

10. Memcached dan Redis untuk caching.

Secara keseluruhan untuk pemain ini adalah server tangki:

• Satu titik otorisasi;
• Obrolan
• Klan;
• Sistem pembayaran;
• Sistem turnamen;
• Game met (Peta global, area yang diperkuat);
• Portal Tank, Portal Klan;
• Manajemen konten, dll.

Tetapi jika Anda melihat, ini adalah hal-hal yang sedikit berbeda yang ditulis pada teknologi yang berbeda. Ini menyebabkan beberapa masalah keandalan.



Diagram menunjukkan server tangki kami beserta ekosistemnya. Ada server permainan, layanan web (internal dan eksternal), termasuk layanan sepenuhnya khusus yang terletak di jaringan backend dan melakukan fungsi layanan, dan layanan kepada mereka, yang benar-benar mengimplementasikan antarmuka. Misalnya, ada layanan klan dengan portal klannya sendiri, yang memungkinkan Anda mengelola klan ini, ada portal gamenya sendiri, dll.

Pemisahan ini memungkinkan kita untuk tidak terlalu khawatir tentang keamanan, karena tidak ada yang memiliki akses ke jaringan internal - lebih sedikit masalah. Tetapi ini mengarah pada upaya tambahan, karena kita membutuhkan proxy yang akan memberikan akses jika kita perlu mendorongnya keluar.

Saya sudah mengatakan bahwa kami membuat keputusan untuk menghapus beberapa logika permainan dan hal-hal lain dari server. Ada tugas untuk memasukkan segala sesuatu ke dalam klien. Kami memiliki Gateway Klien yang luar biasa yang memungkinkan klien tank untuk secara langsung mengakses server dari beberapa API Layanan Internal ini - klan atau API yang sama dari meta-game kami.

Plus, kami mendorong Chromium Embedded Framework (CEF) di dalam klien tangki. Kami sekarang memiliki browser yang sama. Pemain tidak membedakannya dari jendela permainan. Ini memungkinkan Anda untuk bekerja dengan seluruh infrastruktur, melewati pekerjaan dengan server game.

Kami memiliki banyak kluster - hal itu terjadi - saya akan memberi tahu Anda alasannya. Inilah yang terlihat seperti wilayah CIS.



Semuanya tersebar di sekitar pusat data. Pemain, tergantung di mana ping lebih baik, sambungkan ke lokasi. Tetapi seluruh ekosistem tidak berskala seperti ini, terutama di Eropa dan Moskow, yang juga menambah beberapa masalah dengan keandalan - latensi ekstra dan penerusan.

Seperti itulah ekosistem World of Tanks.

Apa yang salah dengan semua ekonomi ini? Apapun yang kamu mau! Dan pergi J. Tapi mari kita pisahkan.

Poin kunci kegagalan dalam sebuah cluster

Kegagalan satu mesin atau proses

Opsi paling sederhana yang dapat kami prediksi adalah kegagalan satu mesin atau proses dalam sebuah cluster. Kami memiliki kelompok dari 10 hingga 100 mobil - sesuatu dapat terbang keluar. Seperti yang saya katakan, BigWorld sendiri menyediakan mekanisme di luar kotak yang memungkinkan kita menjadi lebih andal.



Skema standar: ada BaseApps yang tersebar di berbagai mesin. Pada BaseApp ini ada entitas yang mengandung entitas negara. Setiap BaseApp mencadangkan dirinya sendiri dengan Round Robin pada yang lain.

Misalkan kita punya file dan beberapa BaseApp mati, atau seluruh mesin mati - tidak apa-apa! BaseApps yang tersisa meninggalkan entitas ini, mereka akan dipulihkan, dan gameplay untuk pemain tidak akan menderita.



CellAPPs melakukan hal yang persis sama, satu-satunya hal adalah mereka menyimpan status mereka pada BaseApps juga, dan bukan pada CellAPP lain.

Tampaknya menjadi mekanisme yang dapat diandalkan, tetapi ...

Anda harus membayar semuanya

Seiring waktu, kami mulai mengamati yang berikut ini.

• Membuat salinan cadangan entitas mulai mengambil semakin banyak sumber daya sistem dan lalu lintas jaringan.

Bahkan, proses pencadangan itu sendiri mulai mempengaruhi stabilitas sistem ketika di dalam klaster sebagian besar jaringan sibuk mengirimkan salinan ke Round Robins.

• Ukuran entitas bertambah seiring berjalannya waktu, ketika atribut baru dan mekanisme permainan ditambahkan.

Tetapi hal yang paling tidak menyenangkan adalah bahwa ukuran entitas ini tumbuh seperti longsoran salju. Misalnya, seorang pemain melakukan beberapa aksi (membeli properti game), dan operasi ini mulai melambat. Kami belum menyelesaikannya, tetapi telah menyimpan perubahan pada atribut ini. Artinya, sistemnya sangat buruk, dan kami masih mulai meningkatkan ukuran cadangan yang perlu dilakukan. Ada efek bola salju.

• Stabilitas sistem secara keseluruhan menurun

Karena kenyataan bahwa kami mencoba untuk melarikan diri dari jatuhnya satu mesin atau proses, kami menjatuhkan stabilitas seluruh sistem.

Apa yang telah kami lakukan untuk mengatasi ini ? Kami memutuskan untuk setiap entitas untuk menyoroti apa yang benar-benar perlu dicadangkan. Kami membagi atribut menjadi bisa berubah dan tidak dapat diubah, dan kami menyalin bukan seluruh entitas, tetapi kami hanya mencadangkan atribut yang dapat berubah. Dengan cara ini, kami hanya mengurangi jumlah informasi yang benar-benar perlu dijaga. Sekarang, ketika menambahkan atribut baru, orang yang melakukan ini harus lebih jelas melihat di mana atribut itu. Tetapi secara umum, ini menyelamatkan kita dari situasinya.

Sejujurnya, mekanisme ini ditetapkan di BigWorld, tetapi di Tanks pada titik tertentu tidak lagi didukung sampai akhir, dan tidak setiap entitas dapat pulih dari cadangannya. Di Kapal, misalnya, para pria mendukung ini. Di sana Anda dapat dengan aman mematikan mesin - informasi hanya akan dipulihkan pada mesin lain, dan klien tidak akan melihat apa pun. Sayangnya, ini tidak selalu terjadi di Tanks, tetapi kami akan mencapai pengembalian semua fungsi ini sehingga berfungsi sebagaimana mestinya.

Kegagalan pusat data. Multi-cluster

Jika tiba-tiba bukan 1-2 mobil jatuh, dan kami mulai kehilangan seluruh pusat data, yaitu cluster sepenuhnya, properti apa yang harus dimiliki sistem agar permainan tidak jatuh dalam situasi seperti itu?

• Setiap cluster harus independen, yaitu:
  
  1. harus memiliki database sendiri;
  2. cluster hanya memproses ruangnya (arena pertempuran).
  Jadi, jika beberapa arena menabrak, yang lain masih bekerja.
• Cluster harus berkomunikasi satu sama lain sehingga orang dapat mengatakan yang kedua: "Aku jatuh!" Ketika naik, data akan dikembalikan dari salinan yang disimpan.
• Anda juga dapat memindahkan pengguna dari satu cluster ke cluster lainnya.

Saat ini, skema multi-cluster kami terlihat seperti ini.



Kami memiliki cluster pusat dan apa yang kami sebut peripheral tempat pertempuran sebenarnya sedang berlangsung. CellApp tidak berjalan di cluster pusat, jika tidak persis sama dengan orang lain. Ini adalah titik pusat pemrosesan akun: mereka naik ke sana, dikirim ke pinggiran, dan di pinggiran sudah ada yang bermain. Artinya, kegagalan dari salah satu cluster tidak menyebabkan hilangnya operabilitas seluruh permainan. Bahkan kegagalan dari cluster pusat tidak memungkinkan pemain baru untuk masuk, tetapi mereka yang sudah bermain di pinggiran dapat melanjutkan permainan.

Fakta bahwa semuanya bekerja untuk kita melalui cluster pusat telah berubah karena pada umumnya teknologi BigWorld sendiri mengasumsikan bahwa ada proses pengelolaan khusus antar manajer klaster. Faktanya, manajer antar-klaster semacam itu dapat dibesarkan.

Secara historis, Tanks membutuhkan multi-cluster, karena mulai longsoran online. Ketika kami mencapai puncak 200 ribu pemain, lalu lintas masuk dari mereka berhenti ditempatkan di pusat data melalui jaringan. Kami harus benar-benar berlutut semacam solusi sehingga pemain dapat diluncurkan ke beberapa pusat data.

Faktanya, kami hanya menang, karena kami sekarang memiliki multi-cluster. Ini juga menjadi berguna bagi pemain, karena ping, yaitu aksesibilitas melalui jaringan, sangat memengaruhi permainan. Jika keterlambatan lebih dari 50-70 ms, ini sudah mulai mempengaruhi kualitas permainan itu sendiri, karena di Tanks semuanya benar-benar dihitung pada server. Tidak ada perhitungan pada klien. Karena itu, perlu diingat bahwa praktis tidak ada yang bisa dilakukan. Tentu saja, beberapa mod dibuat di sana, tetapi mereka tidak memengaruhi proses itu sendiri. Anda dapat mencoba menebak apa yang akan terjadi, tetapi untuk memengaruhi mekanik game itu sendiri - tidak.

Karena pendekatan ini, kluster pusat kami telah menjadi titik kegagalan . Semuanya tertutup baginya. Kami memutuskan - karena mesin ini dan basis permainan besar berdiri di sana, biarkan periferal kami berurusan secara eksklusif dengan pertempuran. Maka benar-benar tidak perlu menyimpan informasi dalam jumlah besar - pertempuran sedang dimainkan dan dimainkan - mari kita kunci semua yang ada di sana.

Untuk benar-benar menulis ulang semuanya untuk menjauh dari konsep cluster pusat, sekarang tidak ada waktu, tidak ada keinginan khusus. Tetapi kami memutuskan, pertama, untuk mengajarkan kluster periferal untuk berkomunikasi satu sama lain. Kemudian kami menggergaji mereka sehingga memungkinkan untuk mempengaruhi mereka menggunakan layanan pihak ketiga.

Sebagai contoh, untuk menciptakan pertempuran sebelumnya, perlu untuk memberitahu kelompok pusat bahwa perlu membuat pertempuran di beberapa pinggiran. Selanjutnya, dengan mekanisme internal, entitas bergerak, esensi arena diciptakan, dll.

Sekarang dimungkinkan untuk secara langsung menghubungi pinggiran, melewati cluster pusat. Jadi kami menghapus pekerjaan ekstra darinya. Tetapi sejauh ini tidak ada keinginan untuk sepenuhnya beralih ke skema di mana semua cluster hampir peer-to-peer, dan semua ini dikendalikan oleh beberapa proses, tetapi tidak pada cluster.

Saya mengingatkan Anda bahwa selain cluster game dengan BaseApps, CellApps, dan lainnya, kami memiliki ekosistem.



Kami mencoba memastikan bahwa kinerja ekosistem tidak memengaruhi permainan. Dalam kasus terburuk, misalnya, sistem turnamen tidak berfungsi, tetapi Anda dapat bermain secara acak - toh, kebanyakan orang bermain secara acak. Ya, kami menurunkan kualitas, tetapi secara umum, Anda dapat bertahan beberapa jam tanpa turnamen.

Ini tidak selalu terjadi. Pertama, sudah ada layanan web yang tertanam dalam game. Misalnya, satu titik otorisasi adalah layanan yang memungkinkan Anda untuk masuk di web atau di suatu tempat di satu tempat, dan benar-benar masuk ke seluruh semesta Wargaming.

Contoh kedua adalah layanan yang melayani pembelian dan transaksi game. Itu juga harus dimasukkan ke dalam permainan hanya karena kami membutuhkan jejak pembelian pemain. Faktanya adalah bahwa di beberapa wilayah kami diwajibkan untuk menampilkan informasi kepada klien tentang apa properti game yang dibeli dengan uang sungguhan dan yang mana untuk uang game. Sistem awalnya tidak menganggap ini, tidak ada yang meletakkannya 5 tahun yang lalu, tetapi hukumnya keras: Anda perlu melakukannya - lakukanlah .

Poin kegagalan ekosistem World of Tanks

Masalah nomor 1. Peningkatan beban

Kami memiliki multi-cluster di mana 10 cluster dengan sejumlah besar mesin. Pemain memainkannya, dan web kecil. Tidak ada yang membeli lima mesin lagi di setiap pusat data. Tetapi pada saat yang sama, kami menyediakan semua fungsi yang sama dan semua yang dibutuhkan tepat di dalam klien. Ini adalah masalah utama.

Interaktivitas dan reaktivitas antarmuka adalah sumber utama dari peningkatan beban ekosistem.

Saya akan memberikan dua contoh dari layanan klan:

1. Anda ingin mengundang pemain lain ke klan. Tentu saja, saya ingin undangan segera menerima pemberitahuan, dan dia akan dapat bergabung dengan Anda. Untuk mengimplementasikan ini, perlu untuk membuat layanan klan entah bagaimana memberi tahu klien, atau membiarkan klien bertanya layanan web dari waktu ke waktu: “Apakah ada yang berubah? Apakah saya punya undangan baru? " Ini adalah opsi pertama dari mana beban tambahan dapat berasal.
2. Tank memiliki rezim yang dibentengi. Misalkan itu dimainkan bukan oleh satu orang, tetapi beberapa. Semua pemain memiliki jendela terbuka dengan area yang dibentengi. Komandan membangun gedung itu. Dianjurkan agar semua orang yang memiliki jendela ini terbuka, bangunan segera muncul.

Keputusan di dahi dengan survei tidak terlalu baik. Faktanya, ini berfungsi, hanya saja Anda perlu mengalokasikan begitu banyak kapasitas untuk ini sehingga fitur ini tidak akan mendatangkan untung bagi perusahaan. Dan jika fitur tersebut tidak mendatangkan untung, maka Anda tidak perlu melakukannya.

Saran pribadi saya tentang cara menangani ini: cara terbaik untuk membuat sistem lebih dapat diandalkan di bawah beban adalah untuk secara umum mengurangi beban entah bagaimana secara logis.

Anda seharusnya tidak dibaringkan dengan besi, menghasilkan sistem yang ketinggalan jaman baru, mengoptimalkan sesuatu - lagi pula, semakin besar bebannya, semakin banyak artefak akan muncul yang tidak dapat Anda hindari. Selain itu, artefak akan terjadi bahkan pada tingkat abstraksi yang lebih rendah dan lebih rendah - pertama dengan aplikasi, kemudian dengan layanan web yang berbeda, maka Anda akan sampai ke jaringan (cisco, dll.). Pada tingkat tertentu, Anda tidak bisa menyelesaikan masalah.

Jika Anda berpikir dengan hati-hati, itu bisa dihindari.

Hal pertama yang kami lakukan adalah mempelajari cara memberi tahu klien melalui server game menggunakan infrastrukturnya. Misalnya, ketika undangan datang ke klan, kami memberi tahu server: "Kami mengundang orang-orang ini dan itu," dan kemudian kluster itu sendiri menemukan orang yang kepadanya pemberitahuan harus dikirim, terutama karena mereka memiliki koneksi. Artinya, kami mendorong dari layanan, dan tidak ada yang terus-menerus menuangkan kami. , , . , , .

— Web-sockets (nginx-pushstream) . , Web-sockets. , Chromium Embedded Framework — , , Web-sockets Nginx. pushstream, Web-sockets .

№ 2.

, , , — . , , — . , , .

? : - , - , , . - , , . .

.



, 120 Game Play . . , , . , . .



3 , :

1. HTTP API;
2. RabbitMQ — ;
3. Apache Kafka .

, , , , , . , - — , . , .



1. HTTP

— HTTP. , , -, . :

• ( , ).
  

, , . , , , Django, 100 200 , API, . , , - 30-40 , , . , — .

• .
  

, , HTTP, — . . — — . , , , , .

• .
  

. . - , - API — API, .

— , . , , . , 10 , - 100 500. , HTTP . nginx' , — .

, HTTP , .

2. RabbitMQ

RabbitMQ BigWord .

• .
  

— - , , , .

• «», , .
  

: . , API: « N — ». , , , , — . , .

«», «», — .

• .
  

RabbitMQ , , , , , , , .

— RabbitMQ .

3. Kafka

, , — Kafka. , RabbitMQ - .

• .
  

, , , . , , . . Kafka. , — , .

• .
  

, . , , - — .

Kafka , , , - , . .

— .



:

• . , - , ..
• — , , , .
• — , . , , .

. , , , entity. . , , .

DLC

, DLC (Development Lifecycle) — , , .



, , . DLC , , . , . , , , .

DLC, . , , , .

DLC, , :

• ( ).

, , «- , », . , , , , .

• : SRE.

, solution-, technical-owner, reability- — , - , game- . , , , . - , , , , . , .

• SRE .

— - . , . , SRE -. SRE , : « , , , — !» , .

QA , , - , , — .

BigWorld Technology «» . , . . « », .

« » , , . — «» (, ) — . , . , - .

: ++. , 40 , . , .

RootConf — DevOpsConf Russia . DevOps 1 2 , . , . , — !