Ваше изначальное утверждение, что решение основанное на Redis недостаточно гибко/масштабируемо/надежно итд.
Я показал пример, что Redis в качестве бэкенда для MQ достаточно серьезное решение, используемое Github, где совсем не: «очень простые очереди с небольшим количеством неважных задач». К примеру Redis-Resque и RabbitMQ вполне конкурирующие системы.
Данные в очередях (которые durable) ПЕРЕЖИВАЮТ РЕСТАРТ RMQ, вот в редисе так точно нельзя
Конечно можно, Redis умеет складывать данные в файловую систему и подхватывать в случае рестарта/поломки. Кроме того, есть репликация.
Система не сможет расти без мэйнстрим траффика.
Это платежные системы, работающие с биткоин, это какие-то магазины подключающие биткоин, это открывающиеся Bitcoin автоматы по всему миру. Это куча стартапов, выросших вокруг BitCoin и получившие инвестиции.
В результате это те же новости на крупных новостных порталах, дающие глоток кислорода в виде нового притока пользователей.
Чем меньше ей будут пользоваться массово и чем меньше система будет подходить под мэйнстрим, тем труднее со временем будет завести/вывести биткоины, поскольку все больше сервисов закроется (а это неудобно для черного рынка).
Соответственно это путь в никуда.
Во время атаки один из майнинг пулов BitFury (16% от всей системы) так и сделали.
Как я понял, они понизили размер блока до 135KB, тем самым повысив минимальную планку комиссии:
Текущий технический потолок системы в 7 транзакций/секунду (7, Карл!) — это курам на смех.
Если не решат эту проблему, — система так и останется бухтой для чернухи и крипто-романтиков, а значит постепенно умрет.
Если же система выкрутится и найдут какое-то элегантное Scalability решение, позволяющее системе стать массовой для использования (очень много надо менять в протоколе) — будет интересно!
Текущий технический потолок системы в 7 транзакций/секунду (7, Карл!) — это курам на смех.
Если не решат эту проблему, — система так и останется бухтой для чернухи и крипто-романтиков, а значит постепенно умрет.
Если же система выкрутится и найдут какое-то элегантное Scalability решение, позволяющее системе стать массовой для использования — будет интересно!
Visa рассчитана на что-то около 60к транзакций/секунду, при обычной нагрузке в 2к транзакций/секунду.
Можно говорить о том, насколько сеть подготовлена к нагрузке.
Bitcoin потолок при текущем размере BlockChain — 7 транзакций/секунду. Достаточно превысить этот пул мусорными транзакциями.
Так что +1,
гипотетическая эффективная атака на Visa обойдется не в тысячи, а в лимоны. Две большие разницы.
И другие замечательные вещи, которые нужно долго и правильно настраивать
Какие еще есть техники/приемы применимые на практике?
Те что можно реально улучшить/как дополнительно защититься, оставив непопулярную парольную политику в качестве крайней меры?
Не всегда даже самые крупные сервисы уделяют достаточное внимание защите от создания простых паролей, а значит, и безопасности аккаунтов пользователей.
У меня немного другое мнение. Раздражают сервисы с подобной политикой:
ваш пароль должен содержать 8+ символов
8? ок, теперь в пароле должна быть заглавная буква
есть заглавная? Теперь добавьте спец-символ
добавили? ок, ок, теперь должна быть хотя бы одна цифра
прошло 6 месяцев, теперь поменяйте пароль снова
Верные методы распугать всех пользователей. И такие методы чаще используются в рунете, чего не скажешь про западный рынок.
Мое утверждение такое: сервис изначально должен работать так, чтоб его было очень-очень сложно/неэффективно брутофорсить (Rate limiting, распознавание/блок опасной активности итд) и система защиты должна быть достаточно стойкой без необходимости раздражать пользователя слишком строгой парольной политикой. В итоге хорошо давать рекомендации (strong/weak), но нельзя заставлять пользователя устанавливать пароль, который он в итоге забудет.
Хорошо работающая система безопасности практически невидима для пользователя!
Защита пароля от перебора — это проблема сервиса, а не проблема пользователя!
Очень важно соблюсти баланс.
Update по поводу безопасности:
В англоязычной ветке обсуждения справедливо заметили, что пример у HipChat есть корпоративная версия, те. чат полностью на своем сервере внутри организации.
Не удивительно, — очень много одинаковых идей но с разной реализацией.
Можно кстати вкратце, какие-то примеры/ссылки, тк. я от электроники отошел лет 6 назад. Совсем не слежу, но интересно.
Я не думаю что мы пооффтопим здесь, речь об автоматизации.
Кстати есть человек который умный дом построил, взяв за контрольный центр st2 (те вся обработка событий построена на этой платформе, что фактически Yaml + Python). Камеры повсюду, сенсоры, админка для доступа извне, https, ключи авторизации (слышал еще пугает заходящих на территорию котов включением автополива газона, что тоже не ново).
Отладка ChatOps команд и сценариев вручную:
Тестируем и хорошо проверяем в Vagrant и Docker: st2workroom, st2express ну и Code reviews, как обычно. Благо, благодаря декларативному подходу и вынесению высокоуровневой логики в Yaml файлы — читать и разбираться легче.
Автоматическое тестирование сценариев и команд:
Есть st2tests, дополнительные Acceptance тесты, когда платформа тестирует некоторые части самой себя с помощью самой себя (картинка выше напомнила). К примеру, вот тест, который проверяет процесс установки/удаления паков. Все это поставляется в виде отдельного пака, те тесты могут быть установлены из внешнего репозитория и запущены как обычный пак (плагин/расширение).
^^ Так же можно поступать для собственных сценариев, тестируя их своими же автоматическими тестами.
Итого, если делать все серьезно для продакшна, может получится 2 репозитория/пака: 1 с вашими командами и сценариями и 1 опциональный с тестами.
И последнее,
реальные команды — они чаще всего состоят из цепочек действий и условий (если случилось 1 -> значит делаем 2, потом 3, потом 4), те что-то массивное складывается в единую ChatOps команду. Чаще всего на продакшене таких команд немного, перепутать — трудно. Самое популярное — это деплой/развертывание.
То что указано в примере с uname -a из чата, когда можно выполнить любую shell конструкцию из чата — это только для простоты демонстрации. Обычно мало смысла такое ставить в продакшн.
Кстати человек бывший GitHub-овец. Можно конечно «обидить хужожника» и сказать что GitHub, Rackspace, Puppet labs, Box итд просто фигней занимаются с этим ChatOps, но коммьюнити сейчас делится на тех, кто это использует и тихонько получает c этого выгоду, и всех остальных.
Вероятно много других компаний используют или хотя бы пробуют в различных подразделениях (но не разглашают), потому что когда скорость реакции, производительность команды увеличивается в х3-х10 раз — это огромные для такого уровня бизнеса деньги.
Как стать коммиттером и действительно ли вам это нужно
Разница между Committer vs Contributor описана здесь:
В эту пятницу пройдет 7-я конференция сообществ DevConf 2016
Хоть бы пост-фактум видео на Youtube увидеть..
Celery: лучшие практики
Ваше изначальное утверждение, что решение основанное на Redis недостаточно гибко/масштабируемо/надежно итд.
Я показал пример, что Redis в качестве бэкенда для MQ достаточно серьезное решение, используемое Github, где совсем не: «очень простые очереди с небольшим количеством неважных задач». К примеру Redis-Resque и RabbitMQ вполне конкурирующие системы.
Конечно можно, Redis умеет складывать данные в файловую систему и подхватывать в случае рестарта/поломки. Кроме того, есть репликация.
По функционалу — пройдитесь по списку resque плагинов и их описанию. Заодно статья за 2009 год будет полезна почему Github написали свой велосипед, перепробовав кучу других MQ:
highscalability.com/blog/2009/11/6/product-resque-githubs-distrubuted-job-queue.html
Я в корне не согласен с трактовкой что Redis как бэкенд для MQ (пример resque) не подходит для серьезных задач и нагрузок. И по функционалу и по скорости (~100K сообщений/секунду на ядро одинаково достижимы как для resque так и для RabbitMQ) и по надежности (миллионы сообщений в сутки не проблема вообще ни для какой MQ).
Celery: лучшие практики
У рубистов есть Resque, который использует Redis в качестве бэкенда.
Resque сделан в GitHub и используется ими в качестве основного MQ. И он действительно быстрый и нагрузку он держит.
Есть очень много имплементаций на других языках и очень хорошая web паель управления (в лучших традициях GitHub).
Security Week 32: Android Stagefright, новые автодыры, Do Not Track 2.0
+1, даже несмотря на субьективно негативное отношение к К.
Bitcoin на пределе? Почему криптовалюту ждут тяжелые времена
Это платежные системы, работающие с биткоин, это какие-то магазины подключающие биткоин, это открывающиеся Bitcoin автоматы по всему миру. Это куча стартапов, выросших вокруг BitCoin и получившие инвестиции.
В результате это те же новости на крупных новостных порталах, дающие глоток кислорода в виде нового притока пользователей.
Чем меньше ей будут пользоваться массово и чем меньше система будет подходить под мэйнстрим, тем труднее со временем будет завести/вывести биткоины, поскольку все больше сервисов закроется (а это неудобно для черного рынка).
Соответственно это путь в никуда.
Bitcoin на пределе? Почему криптовалюту ждут тяжелые времена
Как я понял, они понизили размер блока до 135KB, тем самым повысив минимальную планку комиссии:
www.reddit.com/r/Bitcoin/comments/3cnrt8/bitfury_pool_16_of_hashrate_drops_their_max_block
Bitcoin на пределе? Почему криптовалюту ждут тяжелые времена
en.bitcoin.it/wiki/Scalability
blog.bitcoinfoundation.org/a-scalability-roadmap
Текущий технический потолок системы в 7 транзакций/секунду (7, Карл!) — это курам на смех.
Если не решат эту проблему, — система так и останется бухтой для чернухи и крипто-романтиков, а значит постепенно умрет.
Если же система выкрутится и найдут какое-то элегантное Scalability решение, позволяющее системе стать массовой для использования (очень много надо менять в протоколе) — будет интересно!
Bitcoin на пределе? Почему криптовалюту ждут тяжелые времена
en.bitcoin.it/wiki/Scalability
blog.bitcoinfoundation.org/a-scalability-roadmap
Текущий технический потолок системы в 7 транзакций/секунду (7, Карл!) — это курам на смех.
Если не решат эту проблему, — система так и останется бухтой для чернухи и крипто-романтиков, а значит постепенно умрет.
Если же система выкрутится и найдут какое-то элегантное Scalability решение, позволяющее системе стать массовой для использования — будет интересно!
Bitcoin на пределе? Почему криптовалюту ждут тяжелые времена
Можно говорить о том, насколько сеть подготовлена к нагрузке.
Bitcoin потолок при текущем размере BlockChain — 7 транзакций/секунду. Достаточно превысить этот пул мусорными транзакциями.
Так что +1,
гипотетическая эффективная атака на Visa обойдется не в тысячи, а в лимоны. Две большие разницы.
Тестирование парольных политик крупнейших веб-сервисов
Какие еще есть техники/приемы применимые на практике?
Те что можно реально улучшить/как дополнительно защититься, оставив непопулярную парольную политику в качестве крайней меры?
Тестирование парольных политик крупнейших веб-сервисов
У меня немного другое мнение. Раздражают сервисы с подобной политикой:
Верные методы распугать всех пользователей. И такие методы чаще используются в рунете, чего не скажешь про западный рынок.
Мое утверждение такое: сервис изначально должен работать так, чтоб его было очень-очень сложно/неэффективно брутофорсить (Rate limiting, распознавание/блок опасной активности итд) и система защиты должна быть достаточно стойкой без необходимости раздражать пользователя слишком строгой парольной политикой. В итоге хорошо давать рекомендации (strong/weak), но нельзя заставлять пользователя устанавливать пароль, который он в итоге забудет.
Хорошо работающая система безопасности практически невидима для пользователя!
Защита пароля от перебора — это проблема сервиса, а не проблема пользователя!
Очень важно соблюсти баланс.
Ansible и ChatOps или как управлять 100+ серверами из чата
Вот короткое (20 мин.), но очень энергичное видео о ChatOps опыте в GitHub (на английском):
ChatOps: Методология и Философия
Освещает такие вопросы:
Ansible и ChatOps или как управлять 100+ серверами из чата
В англоязычной ветке обсуждения справедливо заметили, что пример у HipChat есть корпоративная версия, те. чат полностью на своем сервере внутри организации.
В Slack enterprise версия «coming soon in 2015».
Скорее всего есть и другие сервисы с hosted версией.
Ansible и ChatOps или как управлять 100+ серверами из чата
Можно кстати вкратце, какие-то примеры/ссылки, тк. я от электроники отошел лет 6 назад. Совсем не слежу, но интересно.
Я не думаю что мы пооффтопим здесь, речь об автоматизации.
Кстати есть человек который умный дом построил, взяв за контрольный центр st2 (те вся обработка событий построена на этой платформе, что фактически Yaml + Python). Камеры повсюду, сенсоры, админка для доступа извне, https, ключи авторизации (слышал еще пугает заходящих на территорию котов включением автополива газона, что тоже не ново).
Ansible и ChatOps или как управлять 100+ серверами из чата
Ansible и ChatOps или как управлять 100+ серверами из чата
Отладка ChatOps команд и сценариев вручную:
Тестируем и хорошо проверяем в Vagrant и Docker: st2workroom, st2express ну и Code reviews, как обычно. Благо, благодаря декларативному подходу и вынесению высокоуровневой логики в
Yamlфайлы — читать и разбираться легче.Автоматическое тестирование сценариев и команд:
Есть st2tests, дополнительные Acceptance тесты, когда платформа тестирует некоторые части самой себя с помощью самой себя (картинка выше напомнила). К примеру, вот тест, который проверяет процесс установки/удаления паков. Все это поставляется в виде отдельного пака, те тесты могут быть установлены из внешнего репозитория и запущены как обычный пак (плагин/расширение).
^^ Так же можно поступать для собственных сценариев, тестируя их своими же автоматическими тестами.
Итого, если делать все серьезно для продакшна, может получится 2 репозитория/пака: 1 с вашими командами и сценариями и 1 опциональный с тестами.
И последнее,
реальные команды — они чаще всего состоят из цепочек действий и условий (если случилось 1 -> значит делаем 2, потом 3, потом 4), те что-то массивное складывается в единую ChatOps команду. Чаще всего на продакшене таких команд немного, перепутать — трудно. Самое популярное — это деплой/развертывание.
То что указано в примере с
uname -aиз чата, когда можно выполнить любую shell конструкцию из чата — это только для простоты демонстрации. Обычно мало смысла такое ставить в продакшн.Ansible и ChatOps или как управлять 100+ серверами из чата
Вот более сложный/реальный пример с созданием из чата Autoscaling группы и авто-заменой упавших серверов на живые:
habrahabr.ru/post/260917/#comment_8479121
Ansible и ChatOps или как управлять 100+ серверами из чата
Вот более серьезный пример: Autoscaling showcase (можно запустить на Vagrant).
Что происходит:
!asg create name=test domain=domain.com min_nodes=1 expand_by=1Видео на английском (листать на 5 минуту, где начинается интересное).
Кстати человек бывший GitHub-овец. Можно конечно «обидить хужожника» и сказать что GitHub, Rackspace, Puppet labs, Box итд просто фигней занимаются с этим ChatOps, но коммьюнити сейчас делится на тех, кто это использует и тихонько получает c этого выгоду, и всех остальных.
Ansible и ChatOps или как управлять 100+ серверами из чата
Вероятно много других компаний используют или хотя бы пробуют в различных подразделениях (но не разглашают), потому что когда скорость реакции, производительность команды увеличивается в х3-х10 раз — это огромные для такого уровня бизнеса деньги.