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, чем новое железо.
- Очень много очень хитрых хитов, без highload хит отработать не успеет.
- Наш сервис — не конечный сайт клиента, а сервис для сервиса, требования к производительности выше обычных.
- Наш сервис тормозит из-за тормозного партнера, на партнера повлиять не можем, highload — костыль вокруг него.
- Фронтенд на любом проекте

В других местах highload не нужен, это просто очередной buzzword за ваши деньги.

Google и другие интернет и high-tech компании известны своими достижениями в корпоративной культуре, управленческих подходах и практиках, отношением к сотрудникам, а также онлайн и оффлайн инструментами для совместной работы.

Многие из этих практик и инструментов организационного дизайна применимы в других индустриях и организациях — от стартапов и корпораций до университетов и государственных структур. Один из ярких примеров такой практики — это система OKR (Objective - Key Results: человеческая замена KPI, применимая в Agile-процессах).

С 2014 года мы с группой единомышленников из GameChangers.ru проводим исследование “Организационный дизайн динамичных организаций” и готовы предоставить анализ и рекомендации по использованию наиболее эффективных инструментов и методов стратегического планирования в следующих сферах:
- как организовано управление информацией и принятие решений,
- как распределены обязанности и ответственность,
- как организовано получение обратной связи сотрудников,
- как культура и основные ценности организации воплощаются в конкретных инструментах и практиках,
- как люди, которые лучше всего подходят для определённых позиций оказываются именно на них — практики приема новых сотрудников и ротация персонала внутри компании.

На текущий момент в фокусе исследования в IТ: Google, Valve, GitHub, LinkedIn, Atlassian, Яндекс, ВКонтакте, JetBrains.

Другие сферы: НИУ ИТМО, Иннополис, РосАтом, СБерБанк, Zappos, Uber, Tesla.

• Главное — не потерять всех клиентов, которые хотят перечислить нам деньги.
• Низкая цена — наше преимущество.
• Мы не можем поднять цену, потому что на рынке такой уровень.
• Нам нужен большой PR.

Базой для доклада станет опыт работы Акселератора ФРИИ с 200+ IT-компаний. Будут разобраны наиболее показательные кейсы.

Захотят ли суровые админы принять модный тренд за основу своей работы? И получится ли изолированно от разработки принести пользу бизнесу?

Это те вопросы, которые мы даже не задавали себе, когда 3 года назад совет директоров поставил перед службой эксплуатации задачу увеличить стабильность сайта.

Я покажу, что находится за горизонтом событий службы эксплуатации. Опишу признаки DevOps, которые служили ориентирами на пути к результату. И опишу инструменты, которые сработали: за 3 года стабильность работы сайта hh.ru выросла в 10 раз.

Как часто вы слышали эти мифы об обучении и развитии сотрудников: «обучение — это очень дорого»; «наймите тренера-эксперта — у него есть правильные ответы на всё»; «а вот мы сейчас обучим сотрудника, а он уйдет к конкурентам»? Они очень распространены, но при этом неверны, а местами даже вредны.

Я расскажу, как мне на практике пришлось столкнуться с ними, и как я с ними боролась. И вот на каком реальном примере: год назад Parallels приобрела крупного разработчика ПО для удаленного доступа к приложениям и виртуальным рабочим столам — компанию 2X Software со штаб-квартирой на Мальте. В связи с этим возникла необходимость предоставить бизнес-поддержку для нового продукта. Но задача осложнялась тем, что до этого момента сопровождение этого софта осуществлялось силами мальтийских сотрудников интуитивно, а наша основная команда специализировалась на клиентской поддержке.

В результате мы оказались в ситуации, когда успех интеграции нового решения в линейку наших продуктов зависел от того, как быстро мы сможем подготовить специалистов для работы в новой реальности технической поддержки: Business VS Consumer. Бизнес требовал от нас быстрых результатов, что в тех условиях мне представлялось просто невозможным. Я не видела, как можно решить данную задачу, используя традиционные методы переподготовки команды.

Пытаясь развеять эти мифы и подготовить специалиста с качественно иными навыками и умениями, я поняла следующее:
- Найти необходимого специалиста новой формации сложно, а переподготовка и традиционные формы обучения текущих кадров не работают. Я расскажу о формах, которые в итоге сработали и принесли достойные результаты. Например, нам удалось сократить время обучения новых сотрудников с 6 до 2 месяцев. А команда, состоящая лишь из 6 инженеров обрабатывает заявки теперь не за 10 часов, а за 1.5 часа.
- Техническая подготовка и “прокачка" сотрудников информацией не повышает эффективность команды, а высокие показатели специалиста по результатам аттестации не гарантируют качественную поддержку: быстрое время ответа клиенту, 100% качество обработки заявок, удовлетворенность клиента более 90%.
- Для переподготовки специалистов не обязательно требуется значительный бюджет и привлечение внешнего тренера-эксперта. Обладая минимальным бюджетом и активно используя внутренние резервы компании, такие как разработка персональных планов обучения ведущими внутренними специалистами, анализ case study, подготовка самими инженерами тренингов по компонентам, проведение Q&A с разработчиками продукта — можно значительно повысить уровень подготовки команды.

Jira всем и каждому, и пусть никто не уйдет обиженным.

Jira — простой в настройке, удобный и гибкий инструмент для автоматизации процессов.
- Почему Jira.
- Для каких проектов и процессов подходит Jira.

Планирование и автоматизация работы в Jira на примере контентного проекта.
- Настройка бизнес-процессов для ведения редакционного плана.
- Сбор и анализ статистики, оценка качества материалов и эффективности авторов.
- Наглядность: графики и отчеты.
- Автоматизация расчетов с авторами материалов и контроль бюджета проекта.

Плюсы внедрения Jira в проекты любого типа.
- Безопасность.
- Удобство и скорость формирования отчетов.
- Быстрый анализ эффективности команды и проекта.
- Экономия времени и порядок в финансовых расчетах.