От переводчика

В 2009 года за рубежом возникло движение, которое назвало себя DevOps. На первый взгляд это разработчики с навыками сисадминов и сисадмины с навыками разработчиков. Но на самом деле это отнюдь не так. Данное подход имеет четкие цели, философию, инструменты и методы, которые только некоторые русскоязычные компании начинают использовать. Мне кажется, что данный подход у нас незаслуженно игнорируется и мне хотелось бы рассказать об 11 вещах, которые нужно знать о DevOps, в частности:

• что такое DevOps
• каковы его ценности
• как он внедряется
• кому он приносит пользу

Надеюсь, этот текст вам понравится.

Введение

В статье хотелось бы поднять вопросы отличия использования Python для web-разработки по сравнению с оной на PHP. Надеюсь, статья не приведет к холиварам, так как она вовсе не о том, какой язык лучше или хуже, а исключительно о технических особенностях Python.

Мы создаем новое поколение веб-приложения Netflix.com, использующего node.js. Вы можете узнать больше о нашем походе из презентации, которую мы представили на NodeConf.eu несколько месяцев назад. Сегодня я хочу поделиться накопленным опытом в настройке производительности нового стека нашего приложения.

Мы впервые столкнулись с проблемами, когда заметили, что задержка запроса в нашем node.js приложении со временем увеличивается. К тому же оно использовало больше ресурсов процессора, чем мы ожидали, и это коррелировало с временем задержки. Нам приходилось использовать перезагрузку как временное решение, пока мы искали причину с помощью новых инструментов и техник аналитики производительности в нашей Linux EC2 среде.

Гироскоп

Гироскоп в iPhone 4 принесёт новую революцию. На мой взгляд, это самое важное из того, что в нём есть. Остальные моменты не столь интересны. Они так или иначе уже давно есть в других смартах. А отличный корпус и экран это очень приятно, но не открытие.

Окно в другой мир

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

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

Мой список книг, которые мне хочется прочесть, изрядно вырос, спасибо топику “запасаемся на зиму”. Под катом вы обнаружите список книг, составленный по комментариям в том топике.

Сегодня я хочу рассказать о том как я мучался с PHPUnit, Selenium RC и Facebook'ом :)

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

Поделюсь теми, на которые подписан я:

INTRO

Добрый день, уважаемое сообщество.
Позвольте представиться. Я бизнес-аналитик, уже десять лет работаю в области разработки заказного программного обеспечения, в последнее время совмещаю роли аналитика и руководителя проектов.

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

Итак, для начала отвечу на главный вопрос: для чего всё это нужно.
Есть несколько причин.

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

• Вы разработчик ПО, руководитель группы разработки, менеджер проекта или его эквивалент.
• Над проектом работает больше одного программиста, желательно — больше трех.
• Вы пробовали все эти скрамы и эджайлы, почувствовали их прелесть, но есть определенные нарекания к догматическому следованию методологии. Возможно, у вас никто не занимается постановкой процессов совсем и задачи просто «накидываются».
• Команда устала (от проекта, от стресса, ...) и в скором времени всех ждут кнуты и пряники.

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

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



Сегодня мы покажем, что Continuous Delivery — это просто и весело! А пользу от него можно получить, встроив его даже частично. Мы в тестировании Яндекса уже несколько лет используем подобный подход для наших библиотек с открытым исходным кодом — Allure Framework или Yandex QATools. Процесс прост, значительно масштабируем и может применяться как для огромных команд из одного человека, так и для маленьких командочек из десятков человек. А самое главное — весь инструментарий доступен в Open Source!

Кстати, до 30 сентября можно подать заявку и поступить в нашу Школу автоматизации процессов разработки в Питере. Обучение в ней бесплатное и будет состоять не только из курса лекций — обязательным этапом станет командная работа над учебным проектом.

А теперь вернёмся к теме. Представьте картину: уютное рабочее место, вы пишете код, добавляете юнит-тесты и отправляете изменения в систему контроля версий, а через пару часов они «выезжают» на боевые сервера. И все при этом работает.

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

1. «Панель: Тренды разработки в высоконагруженных интернет-проектах».
Алексей fisher Рыбак (Badoo) собрал вместе лучших экспертов из Яндекса, Mail.ru, 2ГИС и Communico и обсудил с ними современные тенденции в разработке и поддержке больших высоконагруженных проектов. Плюс эксперты рассказали об интересных решениях и поделились личным опытом.

Доброго времени суток. В данной статье рассказ пойдет о нескольких возможных атаках на сетевое оборудование, защититься от которых поможет правильная конфигурация коммутаторов.

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

Рассматриваться будут:

• Rogue DHCP Server
• DHCP starvation
• CAM-table overflow
• VLAN hopping
• MAC-spoofing

За основу взят видеоурок CBT nuggets из цикла CCNA security.

Дисклеймер от автора (автор — девушка): Я не разрабатываю движки баз данных. Я создаю веб-приложения. Я участвую в 4-6 разных проектах каждый год, то есть создаю много веб-приложений. Я вижу много приложений с различными требованиями и различными потребностями хранения данных. Я разворачивала большинство хранилищ, о которых вы слышали, и несколько, о которых даже не подозреваете.

Несколько раз я делала неправильный выбор СУБД. Эта история об одном таком выборе — почему мы сделали такой выбор, как бы узнали что выбор был неверен и как мы с этим боролись.Это все произошло на проекте с открытым исходным кодом, называемым Diaspora.

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

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

Всё ниженаписанное касается компаний/отделов, в которых работает работает квалифицированный персонал, то есть курсы «офис для начинающих» им не нужны. Так же как не нужны групповые политики на рабочих станций и специальный админ для перекладывания ярлычков на рабочем столе и установки любимой программы. Другими словами, это бэк-офис айтишников, значительно отличающийся от бэк-офиса остальных отделов.

Краткий спойлер содержимого: VCS, репозиторий исходного кода, code-review, build-сервера, CI, таск-трекер, вики, корпоративный блог, функциональное тестирование, репозиторий для пакетов, система управления конфигурацией, бэкапы, почта/jabber.

Картинка с фрагментом обсуждаемой инфраструктуры:

Мы решили работать без офиса с самого начала. Пожалуй, для маленького агентства переводов, нацеленного на работу с IT-компаниями через интернет, это было довольно логично. Сейчас, спустя 10 лет, в Alconost трудится более 300 человек со всех уголков земного шара. Это не только переводчики, а и маркетологи, специалисты по контекстной рекламе, продажники, редакторы, менеджеры по локализации, специалисты по изготовлению видеороликов. Мы по-прежнему считаем, что офис – это неэффективно, и при этом прекрасно себя чувствуем. На правах сооснователя компании я, Кирилл Клюшкин, могу рассказать, как нам это удается.

Так получилось, что тесть и теща у меня доктора педагогических наук. Что приводит к тому, что волей-неволей начинаешь постигать различные полезные методики :)

Однажды, после какого-то ученого совета за виски чаем на кухне тесть говорит: Саш, а вот как ты считаешь, почему люди чего-то не делают?

Честно сказать, вопрос поставил меня в тупик. Я начал фантазировать: ну, обстоятельства мешают, черты характера, недостаток опыта…

Не-не, сказал, тесть, все не так. Если люди чего-то не делают, для этого может быть 4 причины. После чего мой арсенал управленческих инструментов пополнился еще одним. И именно об этом инструменте мы сегодня поговорим, а заодно разберем несколько историй из реальной жизни:

• Почему менеджеров проектов надо пересаживать в отдельное здание
• Что делать, когда ваш заказчик не пользуется вашей системой отчетов
• Как раскачать low-performer’а

.

Хочу рассказать вам про то как имея в интернете свой VPS-сервер можно поднять туннель в домашнюю сеть. И не платить при этом за статический IP провайдеру, и даже находясь за NAT, все равно сделать доступными в интернете свои домашние сервисы.

С радостью делимся второй частью докладов с конференции для тестировщиков LoveQA, которую мы проводили в середине февраля. Первую часть докладов можно посмотреть по ССЫЛКЕ.

Доклады

«Selenium тесты. От RC и одного пользователя к WebDriver, Page Object и пулу пользователей».
Виталий Котов, Badoo.





«Как мы разгоняли тесты — от баш-скриптов до облака».
Илья Relz Кудинов, Badoo.

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

Самая значимая вещь, которая делает код в компании Google таким хорошим проста — code review (далее CR). Google не единственная компания, использующая CR. Всем известно, что это хорошая идея и множество разработчиков делают это. Но я не видел ни одной другой большой компании, в которой CR был бы так грамотно внедрен. В Google ни одна линия кода не уходит в production пока не получит позитивную оценку на CR.

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

Что же вы получите от использования CR?