Seminggu yang lalu, saya berbicara pada pertemuan Node.JS, dan saya berjanji banyak untuk memposting rekaman kinerja. Kemudian saya menyadari bahwa saya tidak dapat mengakomodasi beberapa fakta menarik dalam waktu setengah jam yang diatur. Ya, dan saya sendiri lebih suka membaca, daripada menonton dan mendengarkan, jadi saya memutuskan untuk memposting presentasi saya dalam format artikel. Namun, video juga akan berada di akhir pos di bagian tautan.
Saya memutuskan untuk memberi tahu Anda tentang titik sakit - hidup dalam monolit. Sudah ada ratusan artikel tentang ini di hub, ribuan salinan dipecah dalam komentar, kebenaran telah lama mati dalam kontroversi, tapi ... Faktanya adalah bahwa kita memiliki pengalaman yang sangat spesifik di OneTwoTrip, tidak seperti banyak orang yang menulis tentang pola arsitektur tertentu di kekosongan:
- Pertama, monolit kita sudah berusia 9 tahun.
- Kedua, ia menghabiskan seluruh hidupnya di bawah beban tinggi (sekarang 23 juta permintaan per jam).
- Dan di NaN, kami menulis monolith kami di Node.JS, yang telah berubah tak bisa dikenali selama 9 tahun terakhir. Ya, kami mulai menulis pada node pada 2010, kami menyanyikan lagu dengan hiruk pikuk pemberani!
Jadi kami memiliki banyak kekhususan dan pengalaman nyata. Menarik? Ayo pergi!
Waktu penafian
Presentasi ini hanya mencerminkan pendapat pribadi penulisnya. Itu mungkin bertepatan dengan posisi OneTwoTrip, atau mungkin tidak bertepatan. Beruntung sekali. Saya bekerja sebagai ahli teknis dari salah satu tim perusahaan dan tidak berpura-pura objektif atau mengungkapkan pendapat seseorang selain pendapat saya.
Penafian Dua
Artikel ini menjelaskan peristiwa sejarah, dan saat ini semuanya salah, jadi jangan khawatir.
0. Bagaimana itu bisa terjadi
Tren permintaan kata "microservice" di google:
Semuanya sangat sederhana - sembilan tahun yang lalu tidak ada yang tahu tentang layanan microser. Jadi kami mulai menulis, seperti orang lain - dalam monolit.
1. Nyeri pada monolit
Di sini saya akan menggambarkan situasi masalah yang kita miliki selama 9 tahun ini. Beberapa dari mereka diselesaikan, beberapa dielakkan dengan retas, beberapa hanya kehilangan relevansi. Tapi ingatan mereka, seperti bekas luka pertempuran, tidak akan pernah meninggalkanku.
1.1 Memperbarui Komponen yang Terhubung
Inilah yang terjadi ketika sinergi itu jahat. Karena komponen apa pun digunakan kembali beberapa ratus kali, dan jika memungkinkan untuk menggunakannya secara bengkok, maka itu tidak hilang. Tindakan apa pun dapat menyebabkan efek yang sama sekali tidak dapat diprediksi, dan tidak semuanya dilacak oleh unit dan tes integrasi. Ingat cerita tentang pel, kipas angin, dan balon? Jika tidak, google saja. Dia adalah ilustrasi terbaik dari kode di monolith.
1.2 Migrasi ke teknologi baru
Apakah Anda ingin Express? Linter? Kerangka kerja lain untuk tes atau moks? Perbarui validator atau setidaknya lodash? Perbarui Node.js? Maafkan aku Untuk melakukan ini, Anda harus mengedit ribuan baris kode.
Banyak yang berbicara tentang keuntungan monolit, yaitu setiap revisi adalah komitmen atom . Orang-orang ini diam tentang satu hal - revisi ini tidak akan pernah dilakukan .
Apakah Anda tahu lelucon lama tentang versi semantik?
semantik sesungguhnya dari versi semantik:
major = perubahan besar
minor = perubahan melanggar minor
patch = perubahan kecil-kecilan
Sekarang bayangkan bahwa setiap perubahan kecil-kecilan hampir pasti akan muncul dalam kode Anda. Tidak, itu mungkin untuk hidup dengannya, dan kami secara berkala mengumpulkan kekuatan dan bermigrasi, tetapi itu benar-benar sangat sulit. Sangat
1.3 Rilis
Di sini saya harus mengatakan tentang beberapa spesifikasi produk kami. Kami memiliki sejumlah besar integrasi eksternal, dan berbagai cabang logika bisnis yang muncul secara terpisah sangat jarang. Saya sangat iri dengan produk yang benar-benar mengeksekusi semua cabang kode mereka dalam 10 menit dalam produksi, tetapi ini tidak terjadi di sini. Melalui trial and error, kami menemukan sendiri siklus rilis optimal yang meminimalkan jumlah kesalahan yang menjangkau pengguna akhir:
- rilis sedang berjalan dan tes integrasi lulus setengah hari
- maka itu di bawah pengawasan yang cermat di atas panggung selama sehari (untuk 10% pengguna)
- kemudian terletak satu hari lagi di produksi di bawah pengawasan yang lebih cermat.
- Dan hanya setelah itu kita memberinya lampu hijau di master.
Karena kami mencintai kolega kami dan tidak merilis pada hari Jumat, pada akhirnya ini berarti bahwa rilis pergi ke master sekitar 1,5-2 kali seminggu. Yang mengarah pada fakta bahwa rilis dapat memiliki 60 tugas atau lebih. jumlah seperti itu menyebabkan konflik gabungan, efek sinergis mendadak, beban kerja penuh QA pada analisis log, dan kesedihan lainnya. Secara umum, sangat sulit bagi kami untuk melepaskan monolit.
1.4 Hanya banyak kode
Tampaknya jumlah kode seharusnya tidak terlalu penting. Tapi ... Tidak juga. Di dunia nyata itu adalah:
- Ambang entri lebih tinggi
- Artefak membangun besar untuk setiap tugas
- Proses CI yang panjang, termasuk tes integrasi, tes unit, dan bahkan kode linting
- Pekerjaan IDE lambat (pada awal pengembangan Jetbrains, kami mengejutkan mereka dengan log kami lebih dari sekali)
- Pencarian kontekstual yang canggih (jangan lupa, kami tidak memiliki pengetikan statis)
- Kesulitan menemukan dan menghapus kode yang tidak digunakan
1.5 Pemilik kode tidak ada
Seringkali tugas muncul dengan lingkup tanggung jawab yang tidak dapat dipahami - misalnya, di perpustakaan terkait. Dan pengembang asli sudah bisa pindah ke tim lain, atau bahkan meninggalkan perusahaan. Satu-satunya cara untuk menemukan pertanggungjawaban dalam kasus ini adalah kesewenang-wenangan administrasi - untuk mengambil dan menunjuk seseorang. Yang tidak selalu menyenangkan bagi pengembang dan orang yang melakukannya.
1.6 Kesulitan debugging
Apakah ingatannya mengalir? Peningkatan konsumsi CPU? Ingin membuat grafik nyala? Maafkan aku Dalam sebuah monolit, begitu banyak hal terjadi pada saat yang sama sehingga menjadi sangat sulit untuk melokalisasi masalah. Sebagai contoh, untuk memahami mana dari 60 tugas ketika memulai produksi menyebabkan peningkatan konsumsi sumber daya (meskipun ini tidak direproduksi secara lokal pada lingkungan pengujian dan pementasan) hampir tidak realistis.
1.7 Satu tumpukan
Di satu sisi, ada baiknya ketika semua pengembang "berbicara" dengan bahasa yang sama. Dalam kasus JS, ternyata bahkan pengembang Backend dengan Frontend saling memahami. Tapi ...
- Tidak ada peluru perak, dan untuk beberapa tugas Anda terkadang ingin menggunakan sesuatu yang lain. Tapi kami punya monolit, dan kami tidak punya tempat untuk menempel pengembang lain.
- Kami tidak bisa hanya mengambil tim yang bagus berdasarkan rekomendasi, yang datang kepada kami atas saran teman - kami tidak punya tempat untuk meletakkannya.
- Seiring waktu, kami bersandar pada kenyataan bahwa pasar tidak memiliki cukup pengembang di tumpukan yang tepat.
1.8 Banyak tim dengan ide berbeda tentang kebahagiaan
Jika Anda memiliki dua pengembang, maka Anda sudah memiliki dua gagasan berbeda tentang kerangka mana yang terbaik, standar mana yang harus dihormati, menggunakan perpustakaan, dan sebagainya.
Jika Anda memiliki sepuluh tim, yang masing-masing memiliki beberapa pengembang, maka ini hanyalah bencana.
Dan hanya ada dua cara untuk menyelesaikannya - baik "demokratis" (semua orang melakukan apa yang diinginkannya), atau totaliter (standar diberlakukan dari atas). Dalam kasus pertama, kualitas dan standardisasi menderita, di kedua - orang yang tidak diizinkan untuk mewujudkan ide kebahagiaan mereka.
2. Keuntungan dari monolit
Tentu saja, ada beberapa keuntungan dalam monolith yang dapat berbeda untuk tumpukan, produk, dan tim yang berbeda. Tentu saja, ada lebih dari tiga, tetapi saya tidak akan bertanggung jawab atas segala yang mungkin terjadi, hanya untuk mereka yang relevan dengan kami.
2.1 Mudah digunakan
Ketika Anda memiliki satu layanan, maka meningkatkan dan menguji jauh lebih mudah daripada selusin layanan. Benar, nilai tambah ini hanya relevan pada tahap awal - misalnya, Anda dapat meningkatkan lingkungan pengujian, dan menggunakan semua layanan, kecuali yang dikembangkan, darinya. Atau dari wadah. Atau yang lainnya.
2.2 Tidak ada overhead transfer data
Cukup plus meragukan, jika Anda tidak memiliki beban yang tinggi. Tetapi kami memiliki kasus seperti itu - oleh karena itu, biaya transportasi antara layanan microser terlihat oleh kami. Tidak peduli bagaimana Anda mencoba melakukan ini dengan cepat, simpan dan transfer semuanya dalam RAM lebih cepat dari yang lainnya - ini jelas.
2.2 Satu unit
Jika Anda perlu memutar kembali suatu saat dalam sejarah, maka melakukannya dengan monolith benar-benar sederhana - ambil dan putar kembali. Dalam hal layanan microser, perlu untuk memilih versi layanan yang kompatibel yang digunakan satu sama lain pada titik waktu tertentu, yang tidak selalu sederhana. Benar, ini juga diselesaikan dengan bantuan infrastruktur.
3. Keuntungan imajiner monolit
Di sini saya mengambil semua hal yang biasanya dianggap plus, tetapi dari sudut pandang saya tidak.
3.1 Kode - ini adalah dokumentasi
Sering mendengar pendapat ini. Tapi biasanya itu diikuti oleh pengembang pemula yang belum melihat file dalam puluhan ribu baris kode yang ditulis oleh orang-orang yang meninggalkan tahun lalu. Nah, untuk beberapa alasan, paling sering titik ini dibawa oleh para pendukung monolit - mereka mengatakan kami tidak memerlukan dokumentasi apa pun, kami tidak memiliki transportasi atau api - semuanya ada dalam kode, mudah dan jelas. Saya tidak akan berdebat dengan pernyataan ini, hanya mengatakan bahwa saya tidak percaya akan hal itu.
3.2 Tidak ada versi perpustakaan, layanan, dan API yang berbeda. Tidak ada repositori yang berbeda.
Ya Tapi tidak. Karena sekilas Anda mengerti bahwa layanan ini tidak ada dalam ruang hampa. Dan di antara sejumlah besar kode dan produk lain yang diintegrasikan - mulai dari perpustakaan pihak ketiga, melanjutkan dengan versi perangkat lunak server, dan tidak berakhir dengan integrasi eksternal, versi IDE, alat CI, dan sebagainya. Dan segera setelah Anda memahami berapa banyak hal berbeda yang dimasukkan dalam layanan Anda secara tidak langsung, segera menjadi jelas bahwa nilai tambah ini hanyalah demagogi.
3.3 pemantauan lebih mudah
Lebih mudah. Karena Anda memiliki, secara kasar, satu dasbor, bukan beberapa lusin. Tetapi ini lebih rumit, dan kadang-kadang bahkan tidak mungkin, karena Anda tidak dapat menguraikan grafik Anda menjadi bagian kode yang berbeda, dan Anda hanya memiliki suhu rata-rata di rumah sakit. Secara umum, saya sudah mengatakan semuanya dalam paragraf tentang kompleksitas debugging, saya hanya akan menjelaskan bahwa kompleksitas yang sama berlaku untuk pemantauan.
3.4 Lebih mudah untuk mematuhi standar umum
Ya Tetapi, seperti yang sudah saya tulis dalam paragraf tentang banyak tim dengan gagasan kebahagiaan - standar-standar itu diberlakukan secara totaliter, atau melemah hampir karena ketiadaan.
3.5 Lebih sedikit peluang duplikasi kode
Pendapat aneh adalah bahwa kode tidak digandakan dalam monolit. Tetapi cukup sering bertemu dengannya. Dalam praktik saya, ternyata duplikasi kode hanya bergantung pada budaya pengembangan di perusahaan. Jika ya, maka kode umum dialokasikan untuk semua jenis perpustakaan, modul, dan layanan mikro. Jika tidak ada di sana, maka akan ada copy-paste dua puluh kali dalam monolit.
4. Pro dari layanan microser
Sekarang saya akan menulis tentang apa yang kami dapatkan setelah migrasi. Sekali lagi, ini adalah kesimpulan nyata dari situasi nyata.
4.1 Anda dapat membuat infrastruktur yang heterogen
Sekarang kita dapat menulis kode pada tumpukan yang optimal untuk menyelesaikan masalah tertentu. Dan itu rasional untuk menggunakan pengembang baik yang datang kepada kami. Misalnya, berikut adalah daftar contoh teknologi yang saat ini kami miliki:
4.2 Anda dapat membuat banyak rilis sering
Sekarang kita dapat membuat banyak rilis independen kecil, dan mereka lebih sederhana, lebih cepat, dan tidak menyakitkan. Dulu kami hanya punya satu tim, tapi sekarang sudah ada 18. Akan ada istirahat jika mereka semua tetap di monolith. Atau orang-orang yang bertanggung jawab untuk itu ...
4.3 Lebih mudah untuk melakukan tes independen
Kami telah mengurangi waktu untuk tes integrasi, yang sekarang menguji hanya apa yang benar-benar berubah, dan pada saat yang sama kami tidak takut dengan efek sinergi yang tiba-tiba. Tentu saja, saya harus mulai berjalan menyapu - misalnya, belajar cara membuat API yang kompatibel ke belakang - tetapi seiring waktu, semuanya beres.
4.4 Lebih mudah untuk mengimplementasikan dan menguji fitur-fitur baru
Sekarang kami terbuka untuk eksperimen. Kerangka kerja, tumpukan, perpustakaan - Anda dapat mencoba semuanya, dan jika berhasil, lanjutkan.
4.5 Anda dapat memperbarui apa pun
Anda dapat memperbarui versi mesin, pustaka, tetapi apa saja! Sebagai bagian dari layanan kecil, menemukan dan memperbaiki semua perubahan yang rusak hanya dalam hitungan menit. Dan tidak berminggu-minggu, seperti sebelumnya.
4.6 Dan Anda tidak dapat memperbarui
Anehnya, ini adalah salah satu fitur paling keren dari layanan microser. Jika Anda memiliki kode kerja yang stabil, maka Anda dapat membekukannya dan melupakannya. Dan Anda tidak perlu memperbaruinya, misalnya, untuk menjalankan kode produk pada mesin baru. Produk itu sendiri bekerja pada mesin baru, dan layanan Microsoft terus hidup seperti semula. Lalat dengan irisan daging akhirnya dapat dimakan secara terpisah.
5 Kekurangan dari Layanan Mikro
Tentu saja, lalat di salep tidak lengkap, dan solusi sempurna untuk hanya duduk dan dibayar tidak berhasil. Apa yang kami temui:
5.1 Perlu bus untuk pertukaran data dan penebangan yang jelas.
Interaksi layanan melalui HTTP adalah model klasik, dan secara umum bahkan yang berfungsi, asalkan ada lapisan logging dan menyeimbangkan di antara mereka. Tetapi lebih baik memiliki ban yang lebih berbeda. Selain itu, Anda harus memikirkan cara mengumpulkan dan menggabungkan kayu di antara mereka sendiri - jika tidak, Anda hanya akan memiliki bubur di tangan Anda.
5.2. Melacak apa yang dilakukan pengembang.
Secara umum, ini harus selalu dilakukan, tetapi dalam layanan mikro, pengembang jelas memiliki lebih banyak kebebasan, yang kadang-kadang dapat menimbulkan hal-hal yang membuat Stephen King merinding. Bahkan jika secara lahiriah kelihatannya layanan tersebut berfungsi - jangan lupa bahwa harus ada orang yang memantau apa yang ada di dalam dirinya.
5.3 Anda memerlukan tim DevOps yang baik untuk mengelola semuanya.
Hampir semua pengembang dapat menggunakan monolith dengan satu atau lain cara dan mengunggah rilisnya (misalnya, melalui FTP atau SSH, saya melihat ini). Tetapi dengan layanan microser, ada segala macam layanan terpusat untuk mengumpulkan log, metrik, dasbor, koki untuk mengelola konfigurasi, volt, jenkins, dan hal-hal baik lainnya, yang tanpanya Anda dapat hidup secara umum - tetapi itu buruk dan tidak dapat dipahami alasannya. Jadi untuk mengelola layanan microser, Anda harus memiliki tim DevOps yang baik.
5.4 Anda dapat mencoba menangkap sensasi dan menembak diri sendiri.
Mungkin ini adalah minus utama dari arsitektur dan bahayanya. Sangat sering orang secara membabi buta mengikuti tren dan mulai memperkenalkan arsitektur dan teknologi tanpa memahaminya. Setelah semuanya jatuh, mereka menjadi bingung dalam kekacauan yang dihasilkan, dan menulis sebuah artikel tentang Habr "bagaimana kita pindah dari layanan microser ke monolith", misalnya. Secara umum, pindah hanya jika Anda tahu mengapa Anda melakukan ini dan masalah apa yang akan Anda pecahkan. Dan yang mana yang Anda dapatkan.
6 Khaki di Monolith
Beberapa peretasan yang memungkinkan kita hidup di monolith sedikit lebih baik dan sedikit lebih lama.
6.1 Linting
Pengenalan linter dalam monolith bukanlah tugas yang sederhana seperti yang terlihat pada pandangan pertama. Tentu saja, Anda dapat membuat aturan ketat, menambahkan konfigurasi, dan ... Tidak ada yang akan berubah, semua orang hanya mematikan linter, karena setengah dari kode berubah menjadi merah.
Untuk secara bertahap memperkenalkan linting, kami menulis add-on sederhana untuk eslint - slowlint , yang memungkinkan Anda melakukan satu hal sederhana - berisi daftar file yang diabaikan sementara. Sebagai hasilnya:
- Semua kode yang salah disorot dalam IDE
- File baru dibuat sesuai dengan aturan linting, jika tidak CI tidak akan ketinggalan
- Yang lama secara bertahap memerintah dan menjauh dari pengecualian
Sepanjang tahun, dimungkinkan untuk membawa sekitar setengah dari kode monolith ke dalam satu gaya, yaitu hampir semua kode yang ditambahkan secara aktif.
6.2 Peningkatan pengujian unit
Setelah unit test dilakukan bersama kami selama tiga menit. Pengembang tidak ingin menunggu terlalu lama, jadi semuanya diperiksa hanya dalam CI di server. Setelah beberapa waktu, pengembang menemukan bahwa tes jatuh, dikutuk, membuka cabang, kembali ke kode ... Secara umum, ia menderita. Apa yang telah kami lakukan dengan ini:
- Sebagai permulaan, kami mulai menjalankan tes di banyak utas. Yandex memiliki varian mocha multi-threaded, tetapi dengan kami itu tidak lepas landas, jadi mereka sendiri menulis pembungkus sederhana. Tes mulai dilakukan satu setengah kali lebih cepat.
- Kemudian kami pindah dari 0,12 node ke yang ke-8 (ya, proses itu sendiri menarik ke laporan terpisah). Aneh seperti kelihatannya, itu tidak memberikan keuntungan mendasar dalam produktivitas pada produksi, tetapi tes mulai dilakukan 20% lebih cepat.
- Dan kemudian kami duduk untuk men-debug tes dan mengoptimalkan secara individual. Yang memberi peningkatan terbesar dalam kecepatan.
Secara umum, saat ini, unit test berjalan di kait persiapan dan bekerja dalam 10 detik, yang cukup nyaman dan memungkinkan Anda untuk menjalankannya tanpa gangguan dari produksi.
6.3 Meringankan berat artefak
Artefak monolit akhirnya memakan waktu 400 megabita. Mengingat fakta bahwa itu dibuat untuk setiap komit, total volume ternyata cukup besar. Modul diare , garpu modul modclean , membantu kami dalam hal ini. Kami menghapus unit test dari artefak dan membersihkannya dari berbagai sampah seperti file readme, tes di dalam paket, dan sebagainya. Kenaikan itu sekitar 30% dari berat!
6.4 Caching Ketergantungan
Sebelumnya, menginstal dependensi menggunakan npm membutuhkan banyak waktu sehingga Anda tidak hanya bisa minum kopi, tetapi juga, misalnya, membuat pizza. Oleh karena itu, pada awalnya kami menggunakan modul npm-cache , yang bercabang dua dan sedikit selesai. Itu memungkinkan Anda untuk menyimpan dependensi pada drive jaringan bersama, yang darinya semua build lain akan mengambilnya.
Kemudian kami memikirkan tentang kemampuan reproduksi majelis. Ketika Anda memiliki monolit, maka perubahan ketergantungan transitif adalah momok Tuhan. Mengingat fakta bahwa kami jauh di belakang versi mesin pada waktu itu, mengubah ketergantungan dari tingkat kelima dengan mudah menghancurkan seluruh perakitan kami. Jadi kami mulai menggunakan npm-shrinkwrap. Sudah lebih mudah baginya, meskipun menggabungkan perubahannya adalah kesenangan bagi yang kuat dalam roh.
Dan kemudian paket-kunci dan perintah npm ci sangat baik akhirnya muncul - yang berjalan pada kecepatan hanya sedikit lebih sedikit daripada menginstal dependensi dari cache file. Karena itu, kami mulai menggunakannya saja, dan berhenti menyimpan perangkat dependensi. Pada hari ini saya membawa beberapa kotak donat untuk bekerja.
6.5 Distribusi urutan rilis.
Dan ini lebih merupakan peretasan administratif, bukan peretnis. Awalnya, saya menentangnya, tetapi waktu menunjukkan bahwa ahli teknis kedua benar dan umumnya dilakukan dengan baik. Ketika rilis didistribusikan secara bergantian antara beberapa tim, menjadi jelas di mana kesalahan itu muncul, dan yang lebih penting, masing-masing tim merasakan tanggung jawabnya untuk kecepatan, dan mencoba untuk memecahkan masalah dan meluncurkan secepat mungkin.
6.6 Menghapus kode mati
Dalam sebuah monolith, sangat menakutkan untuk menghapus kode - Anda tidak pernah tahu di mana Anda bisa terjebak dengannya. Karena itu, paling sering hanya tetap berbaring miring. Selama bertahun-tahun. Dan bahkan kode mati harus didukung, belum lagi kebingungan yang diperkenalkannya. Oleh karena itu, seiring waktu, kami mulai menggunakan analisis-kebutuhan untuk pencarian kode mati yang dangkal, dan tes integrasi plus peluncuran dalam mode pemeriksaan cakupan untuk pencarian yang lebih dalam.
7 potong Monolith
Untuk beberapa alasan, banyak orang berpikir bahwa untuk beralih ke layanan microser, Anda perlu meninggalkan monolith Anda, menulis banyak layanan microser di dekat awal, menjalankan semuanya sekaligus - dan akan ada kebahagiaan. Tapi model ini ... Hmm ... Itu penuh dengan fakta bahwa Anda tidak akan melakukan apa-apa, dan hanya menghabiskan banyak waktu dan uang untuk menulis kode yang harus Anda buang.
Saya mengusulkan opsi lain, yang menurut saya lebih berfungsi, dan yang diterapkan bersama kami:
- Kami mulai menulis layanan baru di microservices. Kami menjalankan teknologinya, melompat menyapu, kami mengerti apakah kami ingin melakukannya sama sekali.
- Kami mengekstrak kode ke modul, perpustakaan, atau apa pun yang digunakan di sana.
- Kami membedakan layanan dari monolith.
- Kami membedakan microservices dari layanan. Tanpa tergesa-gesa dan satu demi satu.
8 Dan akhirnya
Pada akhirnya, saya memutuskan untuk meninggalkan hal yang paling penting.
Ingat:
- Anda bukan google
- Anda bukan microsoft
- Anda bukan facebook
- Anda bukan Yandex
- Anda bukan netflix
- Anda bukan OneTwoTrip
Jika sesuatu bekerja di perusahaan lain, sama sekali bukan fakta bahwa itu akan menguntungkan Anda. Jika Anda mencoba menyalin secara membabi buta pengalaman perusahaan lain dengan kata-kata "itu bekerja untuk mereka," maka ini kemungkinan besar akan berakhir dengan buruk. Setiap perusahaan, setiap produk, dan setiap tim adalah unik. Apa yang berhasil untuk beberapa tidak akan bekerja untuk yang lain. Saya tidak suka mengatakan hal-hal yang jelas, tetapi terlalu banyak orang mulai membangun kultus kargo di sekitar perusahaan lain, meniru pendekatan secara membabi buta, dan mengubur diri mereka di bawah dekorasi pohon Natal palsu. Jangan lakukan itu. Eksperimen, coba, kembangkan solusi yang optimal untuk Anda. Dan hanya dengan begitu semuanya akan beres.
Tautan yang bermanfaat: