HighLoad++ - крупнейшая в России профессиональная IT-конференция. Более 200 докладов по тематике высоких нагрузок, более 3000 участников. Программа охватывает такие аспекты веб-разработки, как архитектура крупных проектов, базы данных и системы хранения, системное администрирование, нагрузочное тестирование, эксплуатация крупных проектов и другие направления, связанные с высоконагруженными системами.
На нашем канале мы публикуем видео докладов с HighLoad+, РИТ+ и других конференций. Самые свежие записи доступны, как обычно, участникам самих конференций и тем, кто купил эти записи.
Приглашаем на конференцию Saint HighLoad++ 2024, которая пройдет 24 и 25 июня в Санкт-Петербурге! Программа, подробности и билеты по ссылке: vk.cc/cuyIqx
"Уезжало фсе в облака" только у дураков и воришек - поскольку даже тогда когда снималось видео было ясно, что западенцы данные начнут воровать. Плюс в перспективе начнут игнорить все запросы по мониторингу. Те кто "уезжал в облака" теперь либо бегают кругами пытаясь данные вернуть - либо уволены. Ну а если честно это все делалось IRL этими людьми просто из-за откатов.
Нет в законодательстве РФ портала госуслуг, вы вводите в заблуждение или некомпетентны. Есть электронное правительство, на портале электронного правительства не упоминается человек или гражданин. Это портал не для граждан. Отсюда следует, что паспорт РФ не является документом гражданина, а является документом МВД РФ, разработанным Правительством РФ по указу некого Президента РФ. Кем являются люди перемещающие паспорта РФ на портал электронного правительства, установить невозможно, в связи с отсутствием такой информации на этом портале. Но установлено точно, что они являются посыльными от МВД РФ по транспортировке паспортов от МВД РФ на портал электронного правительства, то есть физическими лицами - работниками МВД РФ по договору о регистрации паспортов РФ.
Говорите о best practices, а разворачиваете 5 серверов.... Сциллу как и кассандру нужно разворачивать в 3х availability зонах, если у вас replication_factor=3, в каждой availability зоне должно быть одинаковое кол-во нод, чтобы не было перекоса данных. А потом настраивать через GossipingPropertyFileSnitch, так, чтобы rack=AZ. В итоге, используя NetworkTopologyStrategy для репликации, у вас каждая реплика будет в своей availability зоне, тем самым вы гарантируете правильную защиту от потери данных и high availability. Нельзя разворачивать все в одной availability зоне, потому что кассандра даже если у вас durability=true, пишет в commitlog только раз в 10 секунд, и между этими 10 секундными интервалами, данные commitlog'a пишутся в оперативку (посмотрите настройку commitlog_sync в scylla.yaml). Если в AZ пропадет свет, то есть большой риск потери данных. Ну и если в одной AZ отрубят свет, с алгоритмом деплоймента, описанным выше, вы все равно сможете читать и писать с уровнем consistency QUORUM. А вообще решение очень странное, зачем архивные данные хранить в еще одной базе данных, когда есть дешевые managed сервисы, как S3, и данные можно хранить в Iceberg, или хотя бы в parquet файлах, которые не нужно менеджить, как ценый кластер базы данных.. Пардон за критику, но меня прям ужасает такая архитектура. Это как говнокод, только в плане архитектуры.
🎯 Key Takeaways for quick navigation: 00:04 *🎤 Introduction and Speaker Background* - Speaker introduces himself and his intentions for the talk, - Provides a brief career history and his approach to leadership and project management. 02:10 *🚩 Understanding Failures in Projects* - Definition and classification of "fail", - Different types of fails: technical, conceptual, business, and social, - Explanation with real-life examples. 05:06 *🚀 Importance of Detecting Potential Failures* - The necessity for engineers to identify potential fails, - Methods for detecting fails within a project, - Steps to mitigate and respond to identified fails. 07:50 *🔧 Practical Example of a Fail: Backup Systems* - Real-world example of a fail involving backup systems, - Issues due to manual processes and lack of automation, - Lessons learned and the importance of automated backup systems. 10:53 *🖥️ Failure in Automating Server Upgrades* - Example of automating server upgrades gone wrong, - Problems caused by not testing procedures properly, - The need for suitable automation tools and ensuring thorough testing. 13:43 *⚠️ Importance of Proper Risk Analysis* - Technical and reputational issues arise from improper decisions, - Lack of tests for single-use tasks and insufficient risk analysis. 14:53 *📉 High Performance Failures in Trading Platforms* - Robots for trading platforms failed to keep up with user demand, - Impro bug fixes leading to system overload, - Misalignment between platform and robot maintenance teams. 17:27 *🧩 Coordination Issues and System Dependencies* - No singular vision for product behavior, - Conflicts between teams responsible for different system components, - Robots and platform integration issues causing operational failures. 17:58 *🛠️ Agile Methodology Misapplications* - Incorrect application of Agile in infrastructure-related projects, - Early server purchases leading to capacity issues, - Importance of choosing suitable methodology for the project type. 21:23 *📨 Large-Scale Messaging System Failures* - Designing a messaging service to handle unrealistic user load, - Long reconnection times for users during server restarts, - Overengineering vs. practical solutions for user reconnections. 26:14 *🚩 Warning Signs in Project Management* - Project over-reliance on investor demands, - Overextended testing and selection of storage solutions, - Signs that a project is stalling or overly focused on minor details. 27:56 *📊 Language Choice in Projects* - The discussion about choosing Groovy as the programming language over Java, - Challenges faced with the asynchronous code and control in projects. 30:01 *🚩 Social and Technical Failures in Projects* - Example of a failed project due to poorly chosen technical implementation, - Importance of recognizing non-technical arguments as red flags in decision-making. 32:17 *🏢 Misalignment Between Business and Development Goals* - Challenges with business planning and development timelines not aligning, - Discussion of the failures resulting from premature business expectations. 34:53 *📉 Identifying Project Red Flags* - Signs that a project is in trouble, such as lack of deliverables after a long period, - Strategies for recognizing when to move on or reassess project roles. 36:04 *📝 Questions and Answers* - Interactive Q&A session with the presenter addressing audience queries, - Discussion on conceptual understanding and systematization issues in projects. 38:04 *💡 Audience Questions on Specific Failures* - Detailed questions about specific project failures mentioned in the talk, - Insights on practical experiences and decision-making during project management. Made with HARPA AI
Представим глобальное распределение - ЦОДы с БД на разных континентах. Переводим сумму денег А > B и одновременно другой транзакцией (в интервале 5 мс) обнуляем баланс А. Выполнится ли перевод, если 30% узлов отключились с интервалом 3 мс?
"Мы думаем о микросервисах с технологической точки зрения". "Облик микросервиса определяет технология на которой мы его строим". Понимаю почему этот пингвин в 50% случаев стоит распределенные монолиты. Но в упор не понимаю, что он делает на сцене?
Скоро слово «микросервисы» перейдут в разряд кринжа. Сейчас микросервисы это как какая-то секта - все о них говорят как о спасении, на всех собесах хотят получить от кандидата глубокие знания микросервисов. Когда это уже закончится ?! 😅
Основная проблема, что все делают микросервисы, но делают их просто монолитом на 10-30-50-100 деплойментах, которые связаны между собой по сети. А еще добавляют 30-50-100 репозиториев, где дублируется код. Мои искренние соболезнования таких архитектурным экспертам.
