Информационный портал по безопасности

Весной 2017 года Eric Simons, со-основатель учебного проекта Thinkster, анонсировал проект «RealWorld» — демо приложение и спецификация к нему. Проект объявил своей целью выйти за рамки привычных «todo»-демок для более прикладного сравнения и изучения возможностей различных фреймворков и технологий, а также подходов к разработке и способов решения задач.

– Г-голубчики, – сказал Федор Симеонович озадаченно, разобравшись в почерках. – Это же п-проблема Бен Б-бецалеля. К-калиостро же доказал, что она н-не имеет р-решения.

– Мы сами знаем, что она не имеет решения, – сказал Хунта, немедленно ощетиниваясь. – Мы хотим знать, как ее решать.

– К-как-то ты странно рассуждаешь, К-кристо… К-как же искать решение, к-когда его нет? Б-бессмыслица какая-то…

– Извини, Теодор, но это ты очень странно рассуждаешь. Бессмыслица – искать решение, если оно и так есть. Речь идет о том, как поступать с задачей, которая решения не имеет. Это глубоко принципиальный вопрос, который, как я вижу, тебе, прикладнику, к сожалению, не доступен. По-моему, я напрасно начал с тобой беседовать на эту тему.



Понедльник начинается в субботу. А. и Б. Стругацкие

Вступление

Любой поиск решения проблемы состоит из ряда шагов вне зависимости от природы проблемы. Такой технологичный подход позволяет достаточно успешно работать над проблемой даже в том случае, если вообще непонятно с какой стороны подступиться к решению.

В этой статье хоть и слегка упоминается специфика местных условий, но сам процесс описан достаточно абстрактно, так что применять его можно хоть для решения ошибок в IT-системе, хоть для поиска неисправностей в бытовой электронике, хоть для решения межличностных конфликтов...

Впервые о «систематической ошибке выжившего» я услышал на примере с дельфинами. Все знают, что иногда они выносят на берег потерпевших кораблекрушение. Какие молодцы!



На самом деле дельфины просто любят толкать предметы носом, и никому не известно, как много утопающих они затолкали еще глубже в океан, а не к берегу. Мы знаем только примеры чудесного спасения, потому что жертвы дельфинов нам уже ничего не расскажут.

Привет, Хабр! Меня зовут Виталий Котов, я работаю в Badoo, в отделе QA. Большую часть времени занимаюсь автоматизацией тестирования. Недавно я столкнулся с задачей максимально быстро развернуть Selenium-тесты для одного из наших проектов. Условие было простое: код должен лежать в отдельном репозитории и не использовать наработки предыдущих автотестов. Ах, да, и нужно было обойтись без CI. При этом тесты должны были запускаться сразу после изменения кода проекта. Отчёт должен был приходить на почту.



Собственно, опытом такого развёртывания я и решил поделиться. Получился своего рода гайд «Как запустить тесты за пару часов».



Поехали!

В предыдущем посте мы рассказали о проектах-финалистах МЕГА Accelerator 2, которые прошли путь от сыроватой идеи до полноценного бизнеса. Но есть множество проектов, которые застревают на ранних этапах: в поисках инвестора, мотивации или смелости для «выхода из сумрака». В этом посте эксперты МЕГА Accelerator расскажут, как можно решить вопросы, которые возникают у таких проектов в начале пути.

Добрый день.



Каждый, кто мало-мальски администрирует Asterisk, сталкивается с такой задачей как объединить несколько серверов между собой. Тут уже не важно какой протокол выбран IAX или SIP, так как не зависимо от протокола будет приблизительно одинаковый набор действий. В этом нет никакой проблемы до тех пор пока у вас сервера можно пересчитать по пальцам одной руки. Если же вам не хватило одной руки, а пальцы на второй уже заканчиваются тогда милости прошу под кат, дабы посмотреть один из способов решения данной проблемы.

Моя предыдущая статья про «Теневой Бан» на реддите получила порядка сотни комментариев на Хабре и, поскольку с тех пор как я ее выложил я узнал много нового по данной теме, я решил написать продолжение.



В данной статье я раскрою дополнительные детали того, как работает автоматизированный теневой бан на реддит.



Спустя пять дней после того, как я отправил письмо администрации с апелляцией про свой статус «теневого бана», я получил вот такой ответ:







Дословный перевод:



"Спасибо, что связались с нами. Ваш аккаунт попался случайно когда [мы] нацеливались на [охотились за] некоторыми спам-сигналами. Вы более не находитесь в теневом бане."



Из ответа становиться понятно, что я был забанен не только случайно но и, при этом, автоматически. Версия об автоматизации теневых банов подтверждается историей, которую рассказал пользователь форума Unity, на котором я так же выложит свою статью:

Вирусы криптовымогатели, плагины майнинга, фишинговые мобильные приложения все чаще показывают нам, на что они способны и на что мы не способны.



При внедрении систем кибербизопасности, компании часто копируют готовые решения. Однако то, что помогает одним компаниям, может навредить другим. В различных компаниях, как правило, складываются уникальные пазлы из различных IT систем, устройств, видов информации, ценностной оценки информации.



Одни компании воспринимают безопасность исключительно, как установку программных средств защиты. Установка брендмауэра и программного обеспечения для обнаружения вторжения часто используется как эффективное средство защиты информации и борьбы с хакерами. Но если сотрудник оставляет пароль на фишинговом сайте или по неосторожности (либо специально) раскрывает свои пароли третьим лицам, даже самое продвинутое программное обеспечение не решит проблему кибербезопасности.

Конкурентоспособность как отдельной компании, так и экономики страны в целом, все больше зависит от информационных технологий. Стремительно растут производительность процессоров, плотность серверов, виртуальных машин, емкость систем хранения… И, конечно, растут потребности в скорости передачи данных. И мало уметь обеспечивать только текущие потребности, важно смотреть вперед и понимать, к чему следует быть готовым завтра, наметив наиболее выгодный и гибкий путь миграции к более высоким скоростям. Чем быстрее развиваются технологии и приложения, тем сложнее решать эту задачу.



В центре цифровой трансформации находятся центры обработки данных (ЦОД). Текущие тенденции развития ЦОДов показывают, что потребность в пропускной способности их сетей будет ежегодно увеличиваться на 25-35%. Архитектура сети ЦОДа должна гарантировать обработку больших объемов трафика и, что не менее важно, масштабирование серверных, сетевых ресурсов и ресурсов систем хранения с наименьшим объемом отключений и переконфигураций.



Традиционная сетевая архитектура, основанная на трехуровневой топологии (доступ–агрегация–ядро), не отвечает новым требования. Она не способна обеспечить поддержку изменений в объемах и направлении передачи данных и адаптироваться к быстрому росту трафика между серверами (этот трафик часто называют «восток–запад»). Кроме того, она далеко не оптимальна для поддержки современных виртуализированных приложений, которым требуется низкая задержка передачи трафика. Поэтому наблюдается переход на новую архитектуру leaf-spine, которую часто называют «сетевой фабрикой».

Эта статья — вольный пересказ доклада, который я посетил на конференции GOTO Berlin 2017: A Crystal Ball to Prioritize Technical Debt.



Изображения из доклада и права на них принадлежат автору @AdamTornhill.



Каждый разработчик в принципе понимает, что такое технический долг. Что в его проекте этот долг наверняка присутствует. Если повезет, он вспомнит несколько кусков кода, которые давно просятся быть переписанными.



Но как формализовать понятие технического долга, чтобы объяснить его другим? И, тем более, объяснить это менеджеру так, чтобы получить одобрение на рефакторинг? Как найти все места в проекте, которые нужно по-хорошему переписать, и как определить, какие из них должны быть переписаны в первую очередь?



Если эти вопросы неоднократно у вас возникали, прошу под кат.