• Как стать коммиттером и действительно ли вам это нужно
  • В эту пятницу пройдет 7-я конференция сообществ DevConf 2016
    0

    Хоть бы пост-фактум видео на Youtube увидеть..

  • Celery: лучшие практики
    0
    Я не понимаю что вы хотите доказать

    Ваше изначальное утверждение, что решение основанное на Redis недостаточно гибко/масштабируемо/надежно итд.
    Я показал пример, что Redis в качестве бэкенда для MQ достаточно серьезное решение, используемое Github, где совсем не: «очень простые очереди с небольшим количеством неважных задач». К примеру Redis-Resque и RabbitMQ вполне конкурирующие системы.

    Данные в очередях (которые durable) ПЕРЕЖИВАЮТ РЕСТАРТ RMQ, вот в редисе так точно нельзя

    Конечно можно, 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: лучшие практики
    0
    В Redis-e есть авторизация и он умеет накапливать в очереди.

    У рубистов есть Resque, который использует Redis в качестве бэкенда.
    Resque сделан в GitHub и используется ими в качестве основного MQ. И он действительно быстрый и нагрузку он держит.

    Есть очень много имплементаций на других языках и очень хорошая web паель управления (в лучших традициях GitHub).
  • Security Week 32: Android Stagefright, новые автодыры, Do Not Track 2.0
    +2
    Security Week — отличный формат!

    +1, даже несмотря на субьективно негативное отношение к К.
  • Bitcoin на пределе? Почему криптовалюту ждут тяжелые времена
    +2
    Система не сможет расти без мэйнстрим траффика.
    Это платежные системы, работающие с биткоин, это какие-то магазины подключающие биткоин, это открывающиеся Bitcoin автоматы по всему миру. Это куча стартапов, выросших вокруг BitCoin и получившие инвестиции.
    В результате это те же новости на крупных новостных порталах, дающие глоток кислорода в виде нового притока пользователей.

    Чем меньше ей будут пользоваться массово и чем меньше система будет подходить под мэйнстрим, тем труднее со временем будет завести/вывести биткоины, поскольку все больше сервисов закроется (а это неудобно для черного рынка).
    Соответственно это путь в никуда.
  • Bitcoin на пределе? Почему криптовалюту ждут тяжелые времена
    0
    Во время атаки один из майнинг пулов BitFury (16% от всей системы) так и сделали.
    Как я понял, они понизили размер блока до 135KB, тем самым повысив минимальную планку комиссии:

    www.reddit.com/r/Bitcoin/comments/3cnrt8/bitfury_pool_16_of_hashrate_drops_their_max_block
  • Bitcoin на пределе? Почему криптовалюту ждут тяжелые времена
    +1
    Две важные ссылки относительно текущей Scalability проблемы и планов BitCoin:

    en.bitcoin.it/wiki/Scalability
    blog.bitcoinfoundation.org/a-scalability-roadmap

    Текущий технический потолок системы в 7 транзакций/секунду (7, Карл!) — это курам на смех.
    Если не решат эту проблему, — система так и останется бухтой для чернухи и крипто-романтиков, а значит постепенно умрет.

    Если же система выкрутится и найдут какое-то элегантное Scalability решение, позволяющее системе стать массовой для использования (очень много надо менять в протоколе) — будет интересно!
  • Bitcoin на пределе? Почему криптовалюту ждут тяжелые времена
    +3
    Две важные ссылки относительно текущей Scalability проблемы и планов BitCoin:

    en.bitcoin.it/wiki/Scalability
    blog.bitcoinfoundation.org/a-scalability-roadmap

    Текущий технический потолок системы в 7 транзакций/секунду (7, Карл!) — это курам на смех.
    Если не решат эту проблему, — система так и останется бухтой для чернухи и крипто-романтиков, а значит постепенно умрет.

    Если же система выкрутится и найдут какое-то элегантное Scalability решение, позволяющее системе стать массовой для использования — будет интересно!
  • Bitcoin на пределе? Почему криптовалюту ждут тяжелые времена
    +3
    Visa рассчитана на что-то около 60к транзакций/секунду, при обычной нагрузке в 2к транзакций/секунду.
    Можно говорить о том, насколько сеть подготовлена к нагрузке.

    Bitcoin потолок при текущем размере BlockChain — 7 транзакций/секунду. Достаточно превысить этот пул мусорными транзакциями.

    Так что +1,
    гипотетическая эффективная атака на Visa обойдется не в тысячи, а в лимоны. Две большие разницы.
  • Тестирование парольных политик крупнейших веб-сервисов
    0
    И другие замечательные вещи, которые нужно долго и правильно настраивать

    Какие еще есть техники/приемы применимые на практике?
    Те что можно реально улучшить/как дополнительно защититься, оставив непопулярную парольную политику в качестве крайней меры?
  • Тестирование парольных политик крупнейших веб-сервисов
    +1
    Не всегда даже самые крупные сервисы уделяют достаточное внимание защите от создания простых паролей, а значит, и безопасности аккаунтов пользователей.


    У меня немного другое мнение. Раздражают сервисы с подобной политикой:
    • ваш пароль должен содержать 8+ символов
    • 8? ок, теперь в пароле должна быть заглавная буква
    • есть заглавная? Теперь добавьте спец-символ
    • добавили? ок, ок, теперь должна быть хотя бы одна цифра
    • прошло 6 месяцев, теперь поменяйте пароль снова

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

    Мое утверждение такое: сервис изначально должен работать так, чтоб его было очень-очень сложно/неэффективно брутофорсить (Rate limiting, распознавание/блок опасной активности итд) и система защиты должна быть достаточно стойкой без необходимости раздражать пользователя слишком строгой парольной политикой. В итоге хорошо давать рекомендации (strong/weak), но нельзя заставлять пользователя устанавливать пароль, который он в итоге забудет.

    Хорошо работающая система безопасности практически невидима для пользователя!
    Защита пароля от перебора — это проблема сервиса, а не проблема пользователя!
    Очень важно соблюсти баланс.
  • Ansible и ChatOps или как управлять 100+ серверами из чата
    0
    Чтобы лучше понимать ChatOps.
    Вот короткое (20 мин.), но очень энергичное видео о ChatOps опыте в GitHub (на английском):

    ChatOps: Методология и Философия

    Освещает такие вопросы:
    • Преимущества ChatOps
    • Использование в реально большой организации
    • C чего начать
    • Примеры из жизни
    • Вопросы безопасности
    • Что стоит делать с помощью ChatOps, а что нет


  • Ansible и ChatOps или как управлять 100+ серверами из чата
    0
    Update по поводу безопасности:
    В англоязычной ветке обсуждения справедливо заметили, что пример у HipChat есть корпоративная версия, те. чат полностью на своем сервере внутри организации.

    В Slack enterprise версия «coming soon in 2015».

    Скорее всего есть и другие сервисы с hosted версией.
  • Ansible и ChatOps или как управлять 100+ серверами из чата
    0
    Не удивительно, — очень много одинаковых идей но с разной реализацией.
    Можно кстати вкратце, какие-то примеры/ссылки, тк. я от электроники отошел лет 6 назад. Совсем не слежу, но интересно.

    Я не думаю что мы пооффтопим здесь, речь об автоматизации.
    Кстати есть человек который умный дом построил, взяв за контрольный центр st2 (те вся обработка событий построена на этой платформе, что фактически Yaml + Python). Камеры повсюду, сенсоры, админка для доступа извне, https, ключи авторизации (слышал еще пугает заходящих на территорию котов включением автополива газона, что тоже не ново).
  • Ansible и ChatOps или как управлять 100+ серверами из чата
    0
    MS поломали Skype ;(
  • Ansible и ChatOps или как управлять 100+ серверами из чата
    +1
    Хороший вопрос.

    Отладка ChatOps команд и сценариев вручную:
    Тестируем и хорошо проверяем в Vagrant и Docker: st2workroom, st2express ну и Code reviews, как обычно. Благо, благодаря декларативному подходу и вынесению высокоуровневой логики в Yaml файлы — читать и разбираться легче.

    Автоматическое тестирование сценариев и команд:
    Есть st2tests, дополнительные Acceptance тесты, когда платформа тестирует некоторые части самой себя с помощью самой себя (картинка выше напомнила). К примеру, вот тест, который проверяет процесс установки/удаления паков. Все это поставляется в виде отдельного пака, те тесты могут быть установлены из внешнего репозитория и запущены как обычный пак (плагин/расширение).

    ^^ Так же можно поступать для собственных сценариев, тестируя их своими же автоматическими тестами.
    Итого, если делать все серьезно для продакшна, может получится 2 репозитория/пака: 1 с вашими командами и сценариями и 1 опциональный с тестами.

    И последнее,
    реальные команды — они чаще всего состоят из цепочек действий и условий (если случилось 1 -> значит делаем 2, потом 3, потом 4), те что-то массивное складывается в единую ChatOps команду. Чаще всего на продакшене таких команд немного, перепутать — трудно. Самое популярное — это деплой/развертывание.
    То что указано в примере с uname -a из чата, когда можно выполнить любую shell конструкцию из чата — это только для простоты демонстрации. Обычно мало смысла такое ставить в продакшн.
  • Ansible и ChatOps или как управлять 100+ серверами из чата
    0
    Интересная идея!

    Вот более сложный/реальный пример с созданием из чата Autoscaling группы и авто-заменой упавших серверов на живые:
    habrahabr.ru/post/260917/#comment_8479121
  • Ansible и ChatOps или как управлять 100+ серверами из чата
    0
    Люди стараются упрощать себе жизнь, и это получается.
    Вот более серьезный пример: Autoscaling showcase (можно запустить на Vagrant).

    Что происходит:
    • Начинается все с ChatOps команды: !asg create name=test domain=domain.com min_nodes=1 expand_by=1
    • Создается Autoscaling группа с серверами в облаке (тут цепочка действий)
    • Платформа слушает состояние серверов через NewRelic API (заменить на свой мониторинг)
    • Дальше происходит интересное, если какой-то сервер в группе падает:
      • 1. система получает триггер из NewRelic что какой-то из серверов упал
      • 2. убирает сервер из Autoscaling группы
      • 3. заменяет его на другой только что поднятый сервер

    • Система сама себя вылечила, вы спите спокойно. Profit!

    Видео на английском (листать на 5 минуту, где начинается интересное).

    Кстати человек бывший GitHub-овец. Можно конечно «обидить хужожника» и сказать что GitHub, Rackspace, Puppet labs, Box итд просто фигней занимаются с этим ChatOps, но коммьюнити сейчас делится на тех, кто это использует и тихонько получает c этого выгоду, и всех остальных.
  • Ansible и ChatOps или как управлять 100+ серверами из чата
    +1
    Кстати, кто из крупных компаний точно использует ChatOps:

    • Github (сами придумали, — сами и используют)
    • RackSpace Сloud
    • Puppet Labs
    • Box.com
    • HP
    • много средних стартапов вроде 500px.com, Pagerduty, VictorOps итд.

    Вероятно много других компаний используют или хотя бы пробуют в различных подразделениях (но не разглашают), потому что когда скорость реакции, производительность команды увеличивается в х3-х10 раз — это огромные для такого уровня бизнеса деньги.
  • Ansible и ChatOps или как управлять 100+ серверами из чата
    +2
    Да, вполне справедливый комментарий.
    На самом деле много споров на эту тему в западном сегменте, есть аргументы как за так и против.

    За:
    • Есть RBAC/Auth Hubot плагин.
    • Можно разрешить определенную группу команд кому надо, запретить кому не надо — очень эффективное и гибкое решение.
    • Можно ли сказать: вот я вам даю ключи и root, пожалуйста выполняйте только 3 команды. С ChatOps так можно сделать.
    • В чат-сервисах вроде Slack можно выставить 2-х факторную аутентификацию. Это значительно повышает безопасность. Учитывая что SSH ключи могут увести, — иногда ChatOps с 2х факторной бывает даже более безопасным решением на практике.

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

    Против:
    • Чат сервис могут взломать. Но скорее всего вы об этом узнаете в новостях и вероятность что взломают Slack чтоб выполнять команды у вас на серверах — очень мала
    • Много прокладок и посредников (кстати интересно какая будет шумиха если взломают GitHub)
    • Насчет против думаю вы меня еще дополните. Вопрос интересный, хочется взглянуть со всех сторон.


    Как безопасно приготовить ChatOps — это пожалуй целая тема для отдельной статьи.
  • Ansible и ChatOps или как управлять 100+ серверами из чата
    +1
    В связи с Jabber внезпано пришла такая сумасшедшая вещь вроде умного дома:
    — Поднимаем собственный Jabber сервер
    — Настраиваем систему и команды
    — Управляем домом из Jabber как с удаленного терминала
    — Заставляем Jabber слать нам уведомления в зависимости от событий: «В доме выключили воду», «Кот запрыгнул на елку», «Позвонили в дверь в 15:32».

    Можно собирать данные с сенсоров, вешать свои обработчики событий if -> then -> else, все на легко читаемом Python-e.
    Потом дополнительно в веб-панель все завернуть, но терминал все равно надо оставить.

    А если интернет временно не доступен на мобильном — как только появится, сообщение с Jabber-a все равно прийдет.

    Есть такие паки для всякой электроники и IoT (интернета вещей):


    Вплоть до какой-то промыленной автоматизации.
  • Ansible и ChatOps или как управлять 100+ серверами из чата
    0
    Можно порулить много еще откуда:

    • IRC
    • HipChat (чат от Atlassian)
    • Skype (!)
    • Jabber (!)
    • Gtalk
    • Gitter
    • Campfire

    Весь список Hubot адаптеров
  • DevOps зоопарк или как 500px обслуживает более 500TB изображений
    0
    По-моему опыту работы/общения с разными DevOps-ами в западных стартапах, как раз лучший набор это люди давно переросшие разработку вцелом, при этом сисадмины, да и еще с хорошим опытом и пониманием бизнес задач.

    ИМХО 2 наиболее часто распространенных мифа про DevOps:
    • «Вася у нас администрирует сервера — он DevOps»
    • «Мы стали использовать Ansible для 2 наших серверов, мы теперь DevOps»

    Просто использование менеджера конфигураций не сделает никого DevOps, так же как и администрирование серверов.

    Из-за «и швец и жнец и на дуде игрец» и требования выше и соответственно зарплата высокая. Очень легко приготовить блюдо DevOps «не так», выбрав на позицию либо зеленого разработчика, либо просто сисадмина, либо того кто не думает о бизнес задачах.

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

    — Вцелом мысль вашу понял и согласен что слово слегка слащавое и раскрученное.
  • DevOps зоопарк или как 500px обслуживает более 500TB изображений
    +1
    По-старому это просто Сисадмины & Разработчики, способные не только понять что программирование — это решение бизнес задач, но и умеющие улучшить кардинально процессы с целью сделать бизнес более эффективным.

    Из этого исходят последствия в виде:
    • оптимизация процессов
    • автоматизация
    • мониторинг
    • инфраструктура Тестирования
    • отслеживание регрессий
    • средства коммуникации в команде
    • внедрение инструментов, которые делают разработку быстрее и качественнее
    • практики единого стиля кодирования, сode reviews и прочие такие мелочи
    • архитектурные изменения/улучшения в коде на основе аналитики
    • инновации и эксперименты
    • итд. список можно долго продолжать


    Итого улучшения Системы вцелом для того, чтобы бизнес работал и рос лучше.
    Те по сути человек и пароход, связывающий Бизнес & Разработку & Качество.
  • DevOps зоопарк или как 500px обслуживает более 500TB изображений
    0
    Update: похоже оба со-основателя 500px наши соотечественники. Пост на GeekTimes 2013 года:
    Один день в офисе 500px. Фото-рассказ

    Там в комментариях хорошая дискуссия про бизнес-модель.
  • DevOps зоопарк или как 500px обслуживает более 500TB изображений
    +1
    www.crunchbase.com/organization/500px

    $525K «посевная» инвестиция в 2011 и $8.8М инвестиций в 2013 «раунд A»

    Как-то так :)

    Кстати похоже один из основателей наш соотечественник (на хабре не смог найти его).
  • DevOps зоопарк или как 500px обслуживает более 500TB изображений
    +1
    Вот интересный пример: 500px.com/photo/111352475/sister-tornados-under-supercell-by-kelly-delay

    Из описания:
    Редкое явление, сестры торнадо из грозовой супер-ячейки надалеко от Симла, Колорадо.
    Снимок всей моей жизни. Я пытался сфотографировать что-то подобное на протяжении 6 лет. Надеюсь вам понравится!


    Фотография свежая (пару дней), сразу попало на Mashable и другие крупные западные новостные ресурсы.
    Получается целая история у фотографии.
  • DevOps зоопарк или как 500px обслуживает более 500TB изображений
    +2
    ИМХО молодцы, откусили свой кусок пирога от рынка супер качественных фотографий. Есть своя группа покупателей и на топовый контент, особенно на западе.

    P.S. Фотки действительно классные.
  • Не мамонт ли Вы? (пятничный тест; который ложь, да в ней намек)
    0
    Согласен. В любых правилах могут быть исключения.

    Вот пример как Yii2 Framework выкрутился, просто добавили свою надстройку для PSR-2:
    github.com/yiisoft/yii2-coding-standards/blob/master/Yii2/ruleset.xml#L6
    github.com/yiisoft/yii2-coding-standards/blob/master/Yii2/Sniffs/Properties/PrivatePropertiesUnderscoreSniff.php

    Все самое хорошее от PSR-2, плюс несколько своих оптимизаций.

    Меня радует вцелом тенденция, движение в сторону каких-то общих стандартов и договоренностей, когда большинство участников только выигрывает.
  • Не мамонт ли Вы? (пятничный тест; который ложь, да в ней намек)
    +1
    Я б еще добавил 2 пункта:
    — Использование PSR, как минимум PSR-2 внутри команды/проекта как единого стиля.
    — Использование PHPDoc для всего. Хорошо не только в целях документации, но и для лучшей поддержки IDE Autocomplete и подсветки ошибок в случае неверных типов данных.

    > Вы правильно используете современные системы контроля версий
    > * Всё должно быть в git-е
    > * Всё — это значит всё! И даже конфиги приложения

    Здесь уместно добавить примечание: все, кроме паролей и токенов.
  • OWASP TOP-10: практический взгляд на безопасность веб-приложений
    0
    Проблема действительно большая, владельцам бизнесов надо на их языке объяснять вред и потенциальные последствия той или иной уязвимости.

    Очень часто сталкиваюсь с отношением владельцев когда буквально говорят: «Adding new features is more priority than fixing security. We don't need that.»
    Когда начинаешь разъяснять возможный ущерб, — лучше приходит понимание, но обычно все равно со скрипом.
  • Yii 2.0.4
    +3
    EachValidator классный!

    Из доков:
    public function rules()
    {
        return [
            // checks if every category ID is an integer
            ['categoryIDs', 'each', 'rule' => 'integer'],
        ]
    }
    
  • Как перевести сайт целиком на постоянный HTTPS для всех
    +1
    Проблема достаточно большая.

    Интерактивная инфографика со средней температурой по интернету для топ 1М сайтов:
    www.trustworthyinternet.org/ssl-pulse

    У четверти сайтов - мусорный F рейтинг
    image


    Те четверть сайтов такие
    image

  • Как перевести сайт целиком на постоянный HTTPS для всех
    0
    Не надо троллить. Там цепочка для поддержки старых браузеров
  • Как перевести сайт целиком на постоянный HTTPS для всех
    +2
    Вы правы, это сугубо субъективная оценка и наверное планка слишком высока.
    Здесь главное не впадать в крайности. Это можно применять к tech-компаниям с 10+ человек в команде, где уже какие-то тех. процессы устоялись и обычно кто-то занимается серверами. Конечно, бесмысленно говорить об очень маленьких компаниях вроде «2 человека и собака» и конечно есть исключения из правил.

    Приведу пример:
    Западный стартап, с помощью которого можно заказать чартер/частный самолет. $6к+ средняя транзакция. Полный букет брешей в SSL тесте — первый плохой знак.
    Смотрим глубже — PHP 5.3 светится в хедерах. Дальше — domain.com/blog/readme.html — старая дырявая версия Wordpress.
    Можно ли уже сказать что-то о технической части проекта? Спрашиваем овнера: «Что происходит?». Оказывается работают индусы за копейки :)

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

    Просто это не единственный фактор, это часть паттерна, некий звоночек.
  • Незваный гость. Почему виртуальные машины — не лучшее решение для приложений завтрашнего дня?
    0
    На момент появления публичного Docker Hub все уже неплохо вертелось: blog.docker.com/2014/06/announcing-docker-hub-and-official-repositories В любом случае, Hub/Registry это важная часть Docker платформы и экосистемы.

    Сыграло все:
    • OpenSource!
    • простота
    • низкий порог вхождения
    • хороший API
    • быстрый движок
    • очень много интеграций
    • четкие и понятные преимущества
    • работает для enterprise/маленьких систем

    Особенно важно выделить огромную работу на публику: Конференции, DockerCon, доклады. Отсюда и куча людей, которые начали его пробовать и нести свой вклад в проект через GitHub (1К contributors!)
    Коммьюнити
    Community

    Для большинства из нас Docker появился внезапно, многие узнали о нем уже будучи популярным. Но вся эта популярность благодаря OpenSource экосистеме и работе с коммьюнити (ну и $150M инвестиций :)

    Это ли не революция? Новый подход при создании приложений
    Dockerized distributed apps

  • Как перевести сайт целиком на постоянный HTTPS для всех
    –2
    У меня уже давно правильно сконфигурированный SSL является одним из факторов оценки IT компании (и ее команды).

    К сожалению, очень многие не парятся и в тестах их SSL www.ssllabs.com/ssltest показывает целый букет брешей.
    Наиболее встречаемые: POODLE, использование слабого RC4, использование SHA1 сертификата вместо SHA2.

    Реально эти тесты косвенно показывают:

    - насколько компания реально заботится о безопасности
    - насколько админ/команда технически подкованы
      - следят за новостями безопасности
      - если такие простые элементы безопасности не учтены, то что же творится в самой системе?
      - косвенно: насколько hire отдел/CEO квалифицирован при выборе работников
    


  • Незваный гость. Почему виртуальные машины — не лучшее решение для приложений завтрашнего дня?
    –1
    Имхо такие вещи как Docker, Vagrant, CoreOS — однозначно революция.

    Просто потому что они сделали уже существующие сложные вещи очень простыми для использования и автоматизации.
  • Как быстро собрать мейлер для колл-центра
    0
    А Mandrill DKIM подписывает с помощью rsa-sha1 или rsa-sha256? Сколько таких почтовых сервисов ни пробывал — все на старом sha1.
    По подобным причинам не нравятся подобные сервисы — нельзя сконфигурировать все под свои нужды.