Картинки к моему рассказу о том, что не всегда круто спешить и бежать впереди паровоза при оптимизации и внедрении новых модных решений. Тезисы тут: http://junior.highload.ru/2016/abstracts/2221.html
ChatOps на практике. Организация работы команды сопровождения / Евгений Потап...Ontico
1. Взаимодействие с командой сопровождения через чаты — преимущества и проблемы.
1.1. ChatOps — о чем это?
1.2. Преимущества взаимодействия и постановки задач через чаты.
1.3. Проблемы хаотичности взаимодействия.
2. Интеграция процессов технической поддержки в ChatOps.
2.1. Постановка задач.
2.2. Мониторинг.
2.3. Оперативное реагирование.
3. Наш опыт доработки Telegram для интеграции с системами постановки задач, мониторингом и мониторингом самого взаимодействия.
Картинки к моему рассказу о том, что такое фреймворки и с чем их едят, что лучше не есть и как выбрать приправы для приготовления. Тезисы тут: http://backendconf.ru/2016/abstracts/2123.html
Картинки к моему рассказу о том, как мы делаем Банки.ру. Некоторые слайды очень неоднозначны без текста. Тезисы тут: http://nastachku.ru/lectures?lecture_id=630#lecture_630
Видео тут https://www.youtube.com/watch?v=m5QuiTZwMrU
Картинки к моему рассказу о том, что не всегда круто спешить и бежать впереди паровоза при оптимизации и внедрении новых модных решений. Тезисы тут: http://junior.highload.ru/2016/abstracts/2221.html
ChatOps на практике. Организация работы команды сопровождения / Евгений Потап...Ontico
1. Взаимодействие с командой сопровождения через чаты — преимущества и проблемы.
1.1. ChatOps — о чем это?
1.2. Преимущества взаимодействия и постановки задач через чаты.
1.3. Проблемы хаотичности взаимодействия.
2. Интеграция процессов технической поддержки в ChatOps.
2.1. Постановка задач.
2.2. Мониторинг.
2.3. Оперативное реагирование.
3. Наш опыт доработки Telegram для интеграции с системами постановки задач, мониторингом и мониторингом самого взаимодействия.
Картинки к моему рассказу о том, что такое фреймворки и с чем их едят, что лучше не есть и как выбрать приправы для приготовления. Тезисы тут: http://backendconf.ru/2016/abstracts/2123.html
Картинки к моему рассказу о том, как мы делаем Банки.ру. Некоторые слайды очень неоднозначны без текста. Тезисы тут: http://nastachku.ru/lectures?lecture_id=630#lecture_630
Видео тут https://www.youtube.com/watch?v=m5QuiTZwMrU
Банки.ру — проект с 10-летней историей. В разные времена мы испытывали разные нагрузки. Портал перестраивался под новые требования как логически, так и технологически, что-то мы меняли в авральном режиме, что-то — эволюционным путём. Сейчас в среднем в день у нас примерно 2КК просмотра страниц, т.е. мы уже не маленькие, но ещё и не совсем большие.
Я хочу поговорить об оптимизации, её своевременности, и о субоптимизации, о том, что далеко не всегда лучшие практики разработки нагруженных систем идут на пользу бизнесу.
Посмотрим примеры и поищем ответы на вопросы:
1) Настолько ли ваш highload — highload?
2) Считать ли хабрэффект поводом для внедрения высоких технологий?
3) "Костыль" или "высокотехнологичное решение" — что выбрать? Плюсы и минусы.
4) Как выбрать момент для начала новой эры? Есть ли критерии, когда имеет смысл начинать оптимизировать ваше приложение и внедрять крутые штуки "по-взрослому".
5) Как можно использовать "список Бунина" для достижения очень неплохих показателей, и все ли пункты реально нужны вам?
6) Как работать с тех. долгом, чтобы он не зарастал мхом?
В заключение я расскажу про несколько примеров из жизни banki.ru в части замены технологических решений в области высоких нагрузок, и что из этого вышло.
P.S. Мнение докладчика может не совпадать с вашим, но это его опыт:)
Поговорим о неотъемлемой составляющей большого числа современных веб-проектов — о фреймворках.
Рассмотрим следующие темы и поищем ответы на вопросы:
1) Что такое фреймворк, и зачем их пишут.
2) Почему для некоторых языков их десятки, а для некоторых — единицы.
3) В чём плюсы и минусы применения.
4) Наиболее распространённые мифы.
5) Использовать или нет — примеры из жизни.
6) Как выбрать из множества доступных вариантов, на что стоит обратить внимание.
Вы слышали о движении #NoEstimates? Разработчики во всем мире отказываются от оценки! Не надо оценивать проекты, фичи и таски — говорят они. Это занимает много времени, да и процесс это не особо приятный.
Вам нравится эта идея? Вижу, что нет.
Вот например, как объяснить заказчику свое новое безоценочное восприятие? Хотите вы или нет, сроки придется называть! Что делать с обязательствами на спринт? А как же прозрачность? Предсказуемость?
По большому счету вы правы. Нельзя просто выкинуть оценку и все. Идея #NoEstimate в том, что можно увеличить прозрачность и предсказуемость разработки, если заменить оценку более эффективными инструментами.
Мы поговорим, что такое на самом деле #NoEstimate и чем практически можно заменить оценку.
Мир меняется очень быстро. То, что казалось нормальным еще несколько лет назад, перестало быть таковым. Например, наши родители не считают, что работа должна приносить удовольствие. Они уверены, что работа должна приносить деньги.
Все поменялось. Теперь все уверены, что работа должна нравится. Если это не так, нужно немедленно эту работу сменить на другую, более развлекающую.
С этим можно спорить и несоглашаться, но победить это уже нельзя. Вопрос в том, можем ли мы это использовать и как это сделать?
Мы поговорим о геймификации, одном из способов этого добиться. Геймификация — это использование игровых подходов вне игрового контекста.
Вот и мы с вами посмотрим, как практики гейм дизайна использовать для улучшения процесса разработки ПО.
Проблемы и решения работы с контентом. Content preparing truobles and soltionsStepan Cheltsov
Чтобы контент появился на сайте, необходимо или полностью всем доверять, или очень много платить. Но есть варианты, при которых процесс будет и управляем и в рамках бюджета с нужным качеством.
Миф об очень сложном Highload / Александр Горный (Mail.Ru Group)Ontico
Highload, высокие нагрузки — популярный и дорогой buzzword, ради него проводятся огромные конференции, разработчики указывают его в резюме, претендуя на большие деньги, а работодатели в вакансиях, обещая более интересную работу.
В докладе я показываю, что современная производительность серверов позволяет не думать о нагрузке для 95% "highload" проектов, знания из конференций не нужны в реальной жизни. Для разработки почти любого, даже очень крупного сайта достаточно PHP+MySQL, здравого смысла и совсем-совсем базовых правил, не обсуждающихся даже на Highload Junior.
План выступления.
1. Ликбез о производительности. RPS, latency — что это значит, как считается, к каким числам надо стремиться? Из чего складывается время отклика? База данных, фронтенд, верстка или мобильное приложение.
2. Замеры достижимой производительности теплого LAMP-ового сервера. Бенчмарк без индексов в базе.
Бенчмарк с индексами в базе. Сравнение с требуемыми цифрами.
3. Перечисление возможных детских ошибок, которые могут испортить эти результаты в жизни. Все эти ошибки объясняются не в академии Highload или институте Highload Junior, а в школе.
Примеры ошибок:
- выгрузка всей базы, а не нужных 20 элементов;
- паразитный вызов тяжелой страницы;
- плохой хостинг;
- чужие тормозные элементы;
- неадекватный объём html/js-кода.
4. Отсутствие детских ошибок позволяет эффективно программировать 90% крупных сайтов, 3-4 приема превратят 90% в 95%.
- nginx;
- репликация;
- кэширование и предрасчет.
Этому, кстати, тоже почти не учат на highload junior, но этому я вас уже научил.
5. Примеры продуктов, в которых на самом деле нужен highload?
- Очень-очень-очень много хитов, дешевле highload, чем новое железо.
- Очень много очен�
Банки.ру — проект с 10-летней историей. В разные времена мы испытывали разные нагрузки. Портал перестраивался под новые требования как логически, так и технологически, что-то мы меняли в авральном режиме, что-то — эволюционным путём. Сейчас в среднем в день у нас примерно 2КК просмотра страниц, т.е. мы уже не маленькие, но ещё и не совсем большие.
Я хочу поговорить об оптимизации, её своевременности, и о субоптимизации, о том, что далеко не всегда лучшие практики разработки нагруженных систем идут на пользу бизнесу.
Посмотрим примеры и поищем ответы на вопросы:
1) Настолько ли ваш highload — highload?
2) Считать ли хабрэффект поводом для внедрения высоких технологий?
3) "Костыль" или "высокотехнологичное решение" — что выбрать? Плюсы и минусы.
4) Как выбрать момент для начала новой эры? Есть ли критерии, когда имеет смысл начинать оптимизировать ваше приложение и внедрять крутые штуки "по-взрослому".
5) Как можно использовать "список Бунина" для достижения очень неплохих показателей, и все ли пункты реально нужны вам?
6) Как работать с тех. долгом, чтобы он не зарастал мхом?
В заключение я расскажу про несколько примеров из жизни banki.ru в части замены технологических решений в области высоких нагрузок, и что из этого вышло.
P.S. Мнение докладчика может не совпадать с вашим, но это его опыт:)
Поговорим о неотъемлемой составляющей большого числа современных веб-проектов — о фреймворках.
Рассмотрим следующие темы и поищем ответы на вопросы:
1) Что такое фреймворк, и зачем их пишут.
2) Почему для некоторых языков их десятки, а для некоторых — единицы.
3) В чём плюсы и минусы применения.
4) Наиболее распространённые мифы.
5) Использовать или нет — примеры из жизни.
6) Как выбрать из множества доступных вариантов, на что стоит обратить внимание.
Вы слышали о движении #NoEstimates? Разработчики во всем мире отказываются от оценки! Не надо оценивать проекты, фичи и таски — говорят они. Это занимает много времени, да и процесс это не особо приятный.
Вам нравится эта идея? Вижу, что нет.
Вот например, как объяснить заказчику свое новое безоценочное восприятие? Хотите вы или нет, сроки придется называть! Что делать с обязательствами на спринт? А как же прозрачность? Предсказуемость?
По большому счету вы правы. Нельзя просто выкинуть оценку и все. Идея #NoEstimate в том, что можно увеличить прозрачность и предсказуемость разработки, если заменить оценку более эффективными инструментами.
Мы поговорим, что такое на самом деле #NoEstimate и чем практически можно заменить оценку.
Мир меняется очень быстро. То, что казалось нормальным еще несколько лет назад, перестало быть таковым. Например, наши родители не считают, что работа должна приносить удовольствие. Они уверены, что работа должна приносить деньги.
Все поменялось. Теперь все уверены, что работа должна нравится. Если это не так, нужно немедленно эту работу сменить на другую, более развлекающую.
С этим можно спорить и несоглашаться, но победить это уже нельзя. Вопрос в том, можем ли мы это использовать и как это сделать?
Мы поговорим о геймификации, одном из способов этого добиться. Геймификация — это использование игровых подходов вне игрового контекста.
Вот и мы с вами посмотрим, как практики гейм дизайна использовать для улучшения процесса разработки ПО.
Проблемы и решения работы с контентом. Content preparing truobles and soltionsStepan Cheltsov
Чтобы контент появился на сайте, необходимо или полностью всем доверять, или очень много платить. Но есть варианты, при которых процесс будет и управляем и в рамках бюджета с нужным качеством.
Миф об очень сложном Highload / Александр Горный (Mail.Ru Group)Ontico
Highload, высокие нагрузки — популярный и дорогой buzzword, ради него проводятся огромные конференции, разработчики указывают его в резюме, претендуя на большие деньги, а работодатели в вакансиях, обещая более интересную работу.
В докладе я показываю, что современная производительность серверов позволяет не думать о нагрузке для 95% "highload" проектов, знания из конференций не нужны в реальной жизни. Для разработки почти любого, даже очень крупного сайта достаточно PHP+MySQL, здравого смысла и совсем-совсем базовых правил, не обсуждающихся даже на Highload Junior.
План выступления.
1. Ликбез о производительности. RPS, latency — что это значит, как считается, к каким числам надо стремиться? Из чего складывается время отклика? База данных, фронтенд, верстка или мобильное приложение.
2. Замеры достижимой производительности теплого LAMP-ового сервера. Бенчмарк без индексов в базе.
Бенчмарк с индексами в базе. Сравнение с требуемыми цифрами.
3. Перечисление возможных детских ошибок, которые могут испортить эти результаты в жизни. Все эти ошибки объясняются не в академии Highload или институте Highload Junior, а в школе.
Примеры ошибок:
- выгрузка всей базы, а не нужных 20 элементов;
- паразитный вызов тяжелой страницы;
- плохой хостинг;
- чужие тормозные элементы;
- неадекватный объём html/js-кода.
4. Отсутствие детских ошибок позволяет эффективно программировать 90% крупных сайтов, 3-4 приема превратят 90% в 95%.
- nginx;
- репликация;
- кэширование и предрасчет.
Этому, кстати, тоже почти не учат на highload junior, но этому я вас уже научил.
5. Примеры продуктов, в которых на самом деле нужен highload?
- Очень-очень-очень много хитов, дешевле highload, чем новое железо.
- Очень много очен�
A presentation I've made for Computer Science students of St. Petersburg State University to talk about the professions within IT sphere. Contains several screenshots from Futurama
RTB и его проблематика должны быть знакомы участникам конференции - мало кто сегодня не слышал об этом способе получить много krps с жесткими ограничениями на время генерации ответа.
Вот и компания Qmobi решила поучаствовать в этой гонке и отхватить свой кусок пирога под названием “рынок мобильной рекламы”.
При первом подходе к снаряду задача выглядит довольно простой: вот запрос с критериями, вот база данных с ответами - выбирай по индексу и отвечай.
На самом деле все несколько сложнее. Начать с того, что некоторые критерии отбора - негативные. Затем мы имеем дело с выборкой по десятку индексов, каждый из которых обладает низкой cardinality. И, наконец, мы имеем дело с большими объемами: около 10М строк в исходных данных, около 10К строк в финальной выборке. Ах, нет, еще финальная выборка должна быть отсортирована по приоритету! И надо не забыть про атомарные блокировку и списание средств...
От идеи прототипа на perl пришлось отказаться еще на этапе постановки задачи :)
Итак, мы имеем задачу с интенсивным IO, высокой нагрузкой, высокими скоростями, сложными структурами данных и эвристическими алгоритмами.
Анализ имеющихся вариантов показал, что Go должен прекрасно подойти для этой задачи. О том, на основании каких соображений мы сделали такой вывод, и какие из этих соображений прошли проверку практикой, а какие - нет, будет рассказано в докладе.
Также в докладе будет рассказано о том, как сортировка была заменена случайной выборкой, и чем пришлось заплатить за то, чтобы эта замена оказалась равноценной.
Будет показано, почему мы наплевательски отнеслись к гипотетической потере 20% возможностей поучаствовать в аукционе, и почему реальный процент потерь много ниже.
Будет раскрыта роль СУБД MySQL в этом проекте, со всем блеском высокой производительности и нищетой отказоустойчивости.
Вопросы геотаргетинга, использования PostGIS и кэширования результатов поиска региона по координатам будут затронуты вскользь, как неоднократно обсуждавшиеся на этой и подобных конференциях.
А вот анатомия производительности приложения на Go будет рассмотрена подробнейшим образом - с графиками и числами.
Также подробно будут рассмотрены наши победы и поражения в борьбе со статис
RTB DSP на языке Go укрощение buzzwords / Даниил Подольский (Qmobi.Com)Ontico
RTB и его проблематика должны быть знакомы участникам конференции — мало кто сегодня не слышал об этом способе получить много krps с жесткими ограничениями на время генерации ответа.
Вот и компания Qmobi решила поучаствовать в этой гонке и отхватить свой кусок пирога под названием “рынок мобильной рекламы”.
Анализ имеющихся вариантов показал, что Go должен прекрасно подойти для этой задачи. О том, на основании каких соображений мы сделали такой вывод, и какие из этих соображений прошли проверку практикой, а какие — нет, будет рассказано в докладе.
Tech Talks @NSU: Рассказ о разных профессиях в IT-индустрии, или почему не вс...Tech Talks @NSU
http://techtalks.nsu.ru
20 февраля 2013. Рассказ о разных профессиях в IT-индустрии, или почему не все выпускники IT-специальностей пишут код (Семён Факторович, Noveo)
«Семен Факторович (Noveo, Новосибирск) рассказывает о разных профессиях в IT-индустрии и о вариантах карьерного роста IT-специалиста»
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
Семён Факторович (Noveo) рассказывает о карьерных лестницах и различных профессиях в IT-индустрии, 20.02.2013
Software Industry 101 — это серия обзорных лекций для студентов Новосибирского государственного университета о профессиях в IT и о реалиях коммерческой разработки софта.
Более подробную информацию, материалы лекций и раписание занятий можно посмотреть на http://bit.ly/industry101
Презентация с доклада на SPDay 14.12.2013.
В докладе описываются приемы и инструменты контроля качества кода решений SharePoint, как для заказчика, так и для подрядчика.
Ромуальд Здебский, Обеспечение качества через интегрированное управление прое...SQADays_2009_Piter
Ромуальд Здебский, Microsoft, Санкт-Петербург, Россия
Обеспечение качества через интегрированное управление проектами разработки ПО - настоящее и будущее
2. Качество продукта и услуги
• Качество vs удовлетворённость
• Удовлетворённость – соответствие ожиданиям
– Продукт: довольные пользователи
– Услуга: довольный заказчик
3. Ещё не заказчик
Принятие решения об аутсорсинге
• Нехватка собственных ресурсов,
(сжатые сроки, и т.п.)
• Требуются рабочие места, офисное пространство
• Нереально быстро найти,
отсобеседовать кандидатов, выбрать
• Неравномерность загрузки:
(пик тестирования перед релизом)
• Высокая стоимость человеко-месяца
• Предыдущий опыт аутсорсинга,
(рекомендации, примеры/антипримеры)
4. ...у заказчика
• Решили аутсорсить !
• Знакомство
• - с компанией-исполнителем
• - с участниками проекта
• Процесс идёт
- исполнители оправдывают ожидания,
- вписываемся в планируемый цикл.
• Ура! Первый релиз! Спасибо!
• Аутсорсить больше задач
5. У аутсорсера
• Подбор команды
• Знакомство
• с продуктом,
документацией, тестами.
• с циклом
• Ручное тестирование
• Подготовка Тест кейсов
• Автоматизация (regression),
в промежутках между фазами
• Возрастание роли автоматизации
6. Путь к счастью
• Регулярно — отчёты
• Метрики
- Число багов.
- Скорость регресс.
– Чем подробнее.. ?
7. ещё к счастью
Регулярно
• Созвоны
– Куда движемся
– Дополнение к письмам
– Эмоционально-
окрашенные
результаты
...
exit-criteria - за представителем заказчика, но ...
9. Отторгает
• Невнятные ответы
• Языковые трудности
• Отсутствие к-л
• «Глупые» вопросы
Рас-шар-кать-ся
• ...
10. В процессе
• Тест кейсы
• - Вики / Tool /почта
• Общие аккаунты для ..
• -Дампо-почта
• - Тest Management tool
• - Сервера, и пр.
• - Экономия на лицензии
• - Нужны договорёности,
«подписи»
11. Хинт: Злой Полицейский
Бывает нужно:
• Тормошить dev заказчика
«Спеки нет, ясности тоже»
• Работать? А деньгами?
А гулять?
Пусть это будет MGR заказчика
12. Случилось страшное
Пропустили баг(и)..
• Провести аудит.
• Сообщить заказчику
о принятых мерах
для предотвращения
подобного.
Напр.:
- Pевью тесткейсов / данных /
- Регулярный статус report...
13. Автоматизация: начало
• Желание автоматизировать регрессионные тесты
• Выбор инструмента, языка (консультации..)
• Начинают
1-2 человека
• Экономить... - ?
14. Авто?
• Итог - через разумное время:
– Автоматизировано
несколько тестов
– Базовый набор
функций/классов
... Так держать?
15. За-Пуски
• Гоняем. Часто FAIL. :
– Конфигурация
– Не та машина
– Не те права
– Изменили UI
– Кривые данные
– Timeout'ы
... 10 раз.. На 11-й бага не ждём?
16. ... Авто - работает!
• Выявлены баги
• % автоматизированного мал
% - метрика, статус!
• Конфигурации –
на откуп автоматизаторам
Это не метрика
(и о конфиг. Мало думают)
– Авторы сами гоняют тесты
– Логов мало, анализ недолгий
(тестов немного)
17. ...А побольше?
• Заказчик хочет больше и быстрее
• Привлечь больше ресурсов
• % автоматизированного – единственная метрика!
• Только авторы
запускают тесты
• О конфигурациях
всё ещё не думают
18. ... Экономить ?
• Экономить на прогонах - “гоняю сам”
(Получается?)
• Пишем вместе
(Нравится?)
• Общаемся регулярно:
– Про FWK напоминаем (вежливо)
– Ревью коммитов
19. «Авто» в идеале
• Запускать умеет любой:
o QA Аутсорсера
(Автор, коллеги)
o QA Заказчика
o Разработчики
(у заказчика, у аутсорсенров..)
o Робот
(Типа Continuous Integration)
• Any
– Конфигурация
– User account
– Domain
20. Бывает ..
• Расширена команда
• Существенно повышен % автоматизированного
• Только авторы прогоняют
• В одной и той же среде
(конфиги)
21. Ещё можно поправить?
o Как только меняется продукт:
o – ОЙ...
o – Логов навалило
(Успевай разбирать!)
o Как бы поскорее...
22. Фатально
• Framework — отсутствует
• Слишком много надо менять
• Не отделаться
Search-and-replace
• Fail, Fail Fail .. Непобедимо!
• ... Stop!
(Кто/что виноват(о,ы) и ...)