~10% места + повышение производительности: странно, что этого еще нет из коробки. Цифра пугающая, и вроде как минусов отдавать ответственность за порядок столбцов на диске на откуп СУБД нет. Ждем в 17 версии :)
Мне кажется, проще поставить какой-нибудь zabbix и настроить алерты в telegram, там это очень просто делается. И он будет мониторить не только доступность, а вообще все параметры сервера, из коробки есть куча шаблонов для почти любого сервиса + можно что угодно настроить самому.
А что поменялось с 2010? Появилась единая точка входа, все кишки спрятали выше document root? Стали придерживаться PSR? Внедрили композер, автотесты, линтер? Перестали велосипедить? Нет :)
К сожалению, это следствие не популярности, а полного игнорирования разработчиками техдлога и всех возможных стандартов сообщества. Кодовая база и архитектура битрикса (кишки наружу, код на массивах с кучей ошибок, без тестов, без анализатора) находится на уровне 2010 года, со всеми вытекающими.
Кто-то может сказать, что они так заботились о юзерах, типа обратная совместимость и обновления, которые можно накатить с любой версии. Ну во-первых, это не так, все равно куча проблем и нужно вручную фиксить много всего, юзерспейс переделывался. Во-вторых - это медвежья услуга, теперь имеем, что имеем.
Еще они известные велосипедисты, со всеми вытекающими. Тут у них в комментах спрашивал про композер - сказали "небезопасно использовать эти ваши доктрины". Пилят какие-то свои неюзабельные поделки на массивах.
Битрикс в таком виде нужно было давно закопать. Если они сейчас в недрах не пилят какой-нибудь "Битрикс 2" как цмс поверх симфони, то скоро их время пройдет.
Насчет того, почему разработчик не может проверить сам - по той же причине, почему не может написать код без багов :)
Особенно сложно хорошо написать тесты на свой же код, потому что ты заранее знаешь как он работает и думаешь только о тех моментах, которые запрограммировал и не думаешь о сценариях, которые забыл продумать.
В итоге картина получается такая: разработчик написал тесты, они работают, все зелененькое, все хорошо. Даже покрытие может быть очень высоким, код приложения в тесте вызывается. Но в тесте может быть допущена ошибка, или пропущен какой-нибудь assert, из-за чего в результате тест не проверяет какую-то важную деталь или сценарий.
Вы не так поняли - мутационные тесты никто не пишет, это запуск тех же самых ваших тестов просто на измененном коде приложения.
Код приложения меняется мутационным фреймворком и на этом коде запускаются ваши тесты. Если тесты проходят, значит тесты не покрывают измененную строку (это может быть условие, вызов метода и тп, вот список мутаций). И так тысячи раз на разные изменения в разных местах.
По факту это единственный способ формально убедиться, что тесты действительно что-то проверяют, не просто работают.
Я позволю себе сослаться на хороший комментарий от @Aquahawkвыше.
Как я и писал в статье, мутационное тестирование - это тяжелая артиллерия, и далеко не всем она нужна.
Не совсем понял, почему вы пишете "генерируем тесты", тесты пишут живые люди пока что (по крайней мере я пока не видел штуку, которая бы по бизнес-требованиям могла создать тест для кода). В этом и есть проблема, что в них тоже могут быть ошибки, они могут не покрывать что-то, или проверять неправильно. Глазами такое почти нереально отловить.
Да, отчет по выжившим мутантам придется смотреть вручную, и думать, делать с ними что-то или не делать.
Ну и не соглашусь насчет нереалистичности покрытия в 70%+, для этого чаще всего достаточно писать по тесту на каждую ручку API, чтобы проверяла основной сценарий.
Я вам могу предложить выбрать самый важный модуль вашей системе и через --filter прогнать по нему мутационные тесты. Если после изучения отчета вы найдете интересные ошибки в тестах или в коде, тогда точно есть смысл.
Не совсем, внедрение мутационных тестов не требует написания еще тестов. Мутационный фреймворк запускает ваши существующие тесты и ищет в них недостатки, проверяя ими измененный код приложения. Тем самым вы просто улучшаете свои тесты :)
Тесты пишут те же люди, что и код - тесты у нас идут как часть решения задачи. На моей основной работе разработка заказная, и поначалу мы пытались выбить время на покрытие тестами у бизнеса - это почти невозможно :)
Поэтому сейчас тесты пишутся как часть решения задачи. Тесты стараемся писать на каждый метод API. Обычные тесты пишем очень давно, но серьезный подход сформировался года 3 назад. И когда у команды есть опыт - тесты не только не замедляют разработку, а значительно ее ускоряют за счет минимизации багов и регрессии. А так тесты набросать занимает не более 10% времени от задачи, это окупается даже на мелких проектах.
Про мутационное тестирование давно слышал, игрался на локалке, но только недавно внедрили его на бой. И эта статья родилась как раз от того, что меня они вдохновили, что на самом деле в первом приближении их внедрение не такое уж и дорогое.
CMS Bitrix и информационная безопасность в одном предложении :) Когда из CMS все кишки наружу торчат без единой точки входа и роутинга - в ней каждый месяц будут находить уязвимости, что в целом и происходит.
Если вы не пользуетесь ispmanager, может стоит его вообще удалить? А ssh оставить только по ключам.
Насчет битрикса: ввиду технических "особенностей" (например отсутствие единой точки входа) этого замечательного продукта, дыры в нем находят часто и будут находить, поэтому лучше зоопарк с битрой хранить в отдельном контуре от важных сайтов. Ну и WAF (тот же cloudflare) будет далеко не лишним.
P.S. спасибо за обзор, радует, когда компании разбирают инциденты
Если данные не нужно сильно модифицировать, то можно использовать вот этот бандл для датахаба. Там можно размапить колонки на поля объектов, есть набор трансформеров, которые можно пайпланить. Но это подойдет для простых кейсов.
Интерфейс
Но если нужно импортировать с какой-то хитрой логикой, мы делаем свой бандл с консольными командами (и/или интерфейсом в админке) и через DAO спокойненько создаем/обновляем объекты. Как и писал в статье - оно удобное, типизированное, IDE все понимает :)
Скорее всего они бы и хотели, только вот наверняка не проводились учения при таких масштабных проблемах. Никто не тренировался с нуля поднимать весь сервис — а там сотни серверов, и не факт, что у них это было полностью автоматизировано.
Почитайте интересную статью про ОК, чтобы понимать масштаб: habr.com/ru/company/odnoklassniki/blog/268413
Кроме того, может и оригиналы видосов тоже потеряны, просто пока не говорят.
Я постоянно думаю о том, когда же начнут зубы клонировать! У вас есть какая-нибудь инфа по исследованиям в эту сторону? Хочется, чтобы в итоге стоматология сместилась в сторону замены зубов родными клонами, а не вот это вот все с удалением нервов, коронками, протезами.
А смысл кого-то наказывать? Обычно инцидент — это вина сразу нескольких человек\отделов: где-то плохо код написали, где-то плохо его проревьюили, где-то плохо протестировали.
Поэтому обычно пытаются подумать над тем, что привело к проблеме и как ее не допустить в будущем.
Например изменением регламентов или вводом новых инструментов.
~10% места + повышение производительности: странно, что этого еще нет из коробки. Цифра пугающая, и вроде как минусов отдавать ответственность за порядок столбцов на диске на откуп СУБД нет. Ждем в 17 версии :)
Мне кажется, проще поставить какой-нибудь zabbix и настроить алерты в telegram, там это очень просто делается.
И он будет мониторить не только доступность, а вообще все параметры сервера, из коробки есть куча шаблонов для почти любого сервиса + можно что угодно настроить самому.
Что не новость про взлом, то Bitrix - https://habr.com/ru/search/?q=Bitrix&target_type=posts&order=date
Не буду повторять свои комментарии
Теперь уже к моему сожалению, это не так.
А что поменялось с 2010? Появилась единая точка входа, все кишки спрятали выше document root? Стали придерживаться PSR? Внедрили композер, автотесты, линтер? Перестали велосипедить? Нет :)
К сожалению, это следствие не популярности, а полного игнорирования разработчиками техдлога и всех возможных стандартов сообщества. Кодовая база и архитектура битрикса (кишки наружу, код на массивах с кучей ошибок, без тестов, без анализатора) находится на уровне 2010 года, со всеми вытекающими.
Кто-то может сказать, что они так заботились о юзерах, типа обратная совместимость и обновления, которые можно накатить с любой версии. Ну во-первых, это не так, все равно куча проблем и нужно вручную фиксить много всего, юзерспейс переделывался. Во-вторых - это медвежья услуга, теперь имеем, что имеем.
Еще они известные велосипедисты, со всеми вытекающими. Тут у них в комментах спрашивал про композер - сказали "небезопасно использовать эти ваши доктрины". Пилят какие-то свои неюзабельные поделки на массивах.
Битрикс в таком виде нужно было давно закопать. Если они сейчас в недрах не пилят какой-нибудь "Битрикс 2" как цмс поверх симфони, то скоро их время пройдет.
Насчет того, почему разработчик не может проверить сам - по той же причине, почему не может написать код без багов :)
Особенно сложно хорошо написать тесты на свой же код, потому что ты заранее знаешь как он работает и думаешь только о тех моментах, которые запрограммировал и не думаешь о сценариях, которые забыл продумать.
В итоге картина получается такая: разработчик написал тесты, они работают, все зелененькое, все хорошо. Даже покрытие может быть очень высоким, код приложения в тесте вызывается. Но в тесте может быть допущена ошибка, или пропущен какой-нибудь assert, из-за чего в результате тест не проверяет какую-то важную деталь или сценарий.
Вы не так поняли - мутационные тесты никто не пишет, это запуск тех же самых ваших тестов просто на измененном коде приложения.
Код приложения меняется мутационным фреймворком и на этом коде запускаются ваши тесты. Если тесты проходят, значит тесты не покрывают измененную строку (это может быть условие, вызов метода и тп, вот список мутаций). И так тысячи раз на разные изменения в разных местах.
По факту это единственный способ формально убедиться, что тесты действительно что-то проверяют, не просто работают.
Я позволю себе сослаться на хороший комментарий от @Aquahawk выше.
Как я и писал в статье, мутационное тестирование - это тяжелая артиллерия, и далеко не всем она нужна.
Не совсем понял, почему вы пишете "генерируем тесты", тесты пишут живые люди пока что (по крайней мере я пока не видел штуку, которая бы по бизнес-требованиям могла создать тест для кода). В этом и есть проблема, что в них тоже могут быть ошибки, они могут не покрывать что-то, или проверять неправильно. Глазами такое почти нереально отловить.
Да, отчет по выжившим мутантам придется смотреть вручную, и думать, делать с ними что-то или не делать.
Ну и не соглашусь насчет нереалистичности покрытия в 70%+, для этого чаще всего достаточно писать по тесту на каждую ручку API, чтобы проверяла основной сценарий.
Я вам могу предложить выбрать самый важный модуль вашей системе и через --filter прогнать по нему мутационные тесты. Если после изучения отчета вы найдете интересные ошибки в тестах или в коде, тогда точно есть смысл.
Не совсем, внедрение мутационных тестов не требует написания еще тестов. Мутационный фреймворк запускает ваши существующие тесты и ищет в них недостатки, проверяя ими измененный код приложения. Тем самым вы просто улучшаете свои тесты :)
Тесты пишут те же люди, что и код - тесты у нас идут как часть решения задачи. На моей основной работе разработка заказная, и поначалу мы пытались выбить время на покрытие тестами у бизнеса - это почти невозможно :)
Поэтому сейчас тесты пишутся как часть решения задачи. Тесты стараемся писать на каждый метод API. Обычные тесты пишем очень давно, но серьезный подход сформировался года 3 назад. И когда у команды есть опыт - тесты не только не замедляют разработку, а значительно ее ускоряют за счет минимизации багов и регрессии. А так тесты набросать занимает не более 10% времени от задачи, это окупается даже на мелких проектах.
Про мутационное тестирование давно слышал, игрался на локалке, но только недавно внедрили его на бой. И эта статья родилась как раз от того, что меня они вдохновили, что на самом деле в первом приближении их внедрение не такое уж и дорогое.
CMS Bitrix и информационная безопасность в одном предложении :)
Когда из CMS все кишки наружу торчат без единой точки входа и роутинга - в ней каждый месяц будут находить уязвимости, что в целом и происходит.
Если вы не пользуетесь ispmanager, может стоит его вообще удалить? А ssh оставить только по ключам.
Насчет битрикса: ввиду технических "особенностей" (например отсутствие единой точки входа) этого замечательного продукта, дыры в нем находят часто и будут находить, поэтому лучше зоопарк с битрой хранить в отдельном контуре от важных сайтов. Ну и WAF (тот же cloudflare) будет далеко не лишним.
P.S. спасибо за обзор, радует, когда компании разбирают инциденты
Все верно, готовый бандл экспорта только для платной лицензии - https://pimcore.com/docs/data-hub-file-export/current/ , придется искать альтернативу или набросать свой бандл под вашу задачу.
В бесплатной есть GraphQL, поэтому отсутствие REST не проблема.
Если данные не нужно сильно модифицировать, то можно использовать вот этот бандл для датахаба. Там можно размапить колонки на поля объектов, есть набор трансформеров, которые можно пайпланить. Но это подойдет для простых кейсов.
Интерфейс
Но если нужно импортировать с какой-то хитрой логикой, мы делаем свой бандл с консольными командами (и/или интерфейсом в админке) и через DAO спокойненько создаем/обновляем объекты. Как и писал в статье - оно удобное, типизированное, IDE все понимает :)
Если интересуют дайджесты по php - их можно найти здесь: https://t.me/phpdigest
Почитайте интересную статью про ОК, чтобы понимать масштаб: habr.com/ru/company/odnoklassniki/blog/268413
Кроме того, может и оригиналы видосов тоже потеряны, просто пока не говорят.
Поэтому обычно пытаются подумать над тем, что привело к проблеме и как ее не допустить в будущем.
Например изменением регламентов или вводом новых инструментов.