Наверх ▲

Облачное хранилище данных "GoDaddy" (GoDaddy.com Cloud Storage)

Адам Кнапп (Adam Knapp) Адам Кнапп (Adam Knapp) Директор по развитию технологий облачного хранения в GoDaddy.com.
Go daddy.com cloud storage adam knapp
View more presentations from Ontico.

Адам Кнапп (Adam Knapp): Добрый день, меня зовут Адам Кнапп. Извиняюсь за технические сложности. Презентация содержит очень много изображений, анимацию. Я постараюсь сделать все возможное, чтобы вписаться во временной график и показать вам большинство слайдов – с тем, чтобы не потерять анимацию, сохранить весь контент.

Итак, добрый день! У нас тут раннее утро. Надеюсь, все в порядке. Хочу поблагодарить за то, что вы предоставили мне возможность здесь сегодня выступать. Хотел бы приехать лично, но, к сожалению, пришлось делать это по телефону. Поэтому прошу прощения.

Сколько в аудитории тех, знаком с программой GoDaddy.com? Есть коммерческая реклама, которая делается с помощью этой программы.

Таким образом, мы получили название для своего бренда. Многие нас знают по нашим доменам. Мы "номер один" в анимации. Вот, посмотрите – это один из вариантов нашего продукта.

Вот как это было сделано.

В основном, мы "номер один" в доменах. Мы, в основном, что-то рекламируем… Каждую секунду, ежедневно обновляем один домен. Вот такая потрясающая работа. Мы также "номер один" в целом ряде сертификатов SSL.

Мы также "номер один" на веб-хостинге. Поддерживаем более 10-ти миллионов заказчиков. Разрабатываем веб-сайты, и все остальное мы тоже делаем.

Это таблица наших продуктов, которую мы недавно составили.

Можно показать разные продукты для разных рынков, которыми мы занимаемся. Это основные продукты, которые мы предлагаем нашим заказчикам. Разные решения хостинга (разделенного, общего). "Облачные" услуги и множество других. У нас есть сайт под приложения (на IPP и другие). Кроме того, занимаемся вопросами безопасности.

Кроме того, у нас есть Dropbox и другие приложения. Есть программа File Folder. Огромное количество разных продуктов для хранения данных. Кроме того, GoDaddy – это еще и программы хранения в "облачных" технологиях.

Анимация... Пока я еще не показывал этого. Посмотрим, как можно здесь проводить навигацию.

Я получил свой диплом в Аризонском государственном университете. Я начинал свою карьеру как разработчик веб-сайтов: работал в Intel, в разных компаниях, которые занимаются веб-хостингом и создают веб-сайты. Потом создал компанию GoDaddy в 2006 году. Там я сначала занимался виртуальным хостингом. Потом у меня были исследовательские программы до 2010-2011 годов.

Это платформы, которые мы разработали для "облачного" хранения.

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

Сегодня я буду говорить об "облачном" хранении.

Посмотрим, где мы участвуем, в каких странах присутствуем.

Достаточно далеко от дома – 6 тысяч миль. Огромное расстояние. GoDaddy работает в разных местах – в США, на Восточном побережье, в Амстердаме, Сингапуре, Индии. Потом мы все-таки собираемся расширяться дальше.

Сегодня мой рассказ – о том, что мы увидим. В основном, это "облачное" хранение и подобные ему технологии.

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

Итак, "облачное" хранение.

У нас много продуктов, которые мы предлагаем, множество возможностей для хранения данных.

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

Итак, первоначально нами двигало стремление снизить затраты по хранению данных.

Вот этот график показывает огромное количество инноваций.

Этот график показывает, как инновации принимаются людьми с течением времени. 2,5 % инноваторов, 13,5 % – те, кто использует эти программы. 34 % ("раннее" большинство) – это те люди, которые на самом деле используют эти новые идеи в программном обеспечении. Затем позднее большинство – 34 %.

16 % – это люди, которые так и не используют инновации, а просто смотрят видео, DVD в традиционных областях.

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

О том, как мы связывали наши процессы и методологии внутри компании для себя, своих собственных решений

Первоначальной задачей было предоставить виртуальный хостинг. Мы разрабатывали продукт, который называется Backup. Решения для резервного копирования в протоколе FTP.

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

Но мы достигли своей цели. Мы сократили затраты. Построили на протоколе FTP специальную систему, которая работала с нашими системами файлов.

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

Нашей следующей задачей в конце 2008 года было решение с Dropbox.

Это было огромное количество всяких предложений, огромные возможности для хранения данных.

Video.me – это еще одна программа, которая была нами разработана. Это конкурент YouTube. Здесь вы сами можете создавать каналы и записывать видео. Эта программа была сделана в ноябре 2009 года.

Контент и видео нам нужно было где-то хранить. Потребовалось создать собственные услуги для хранения этого контента. Мы создали эти ресурсы в феврале. Это предоставило нам возможность нанять еще двух разработчиков и еще одного специалиста по качеству. Я и Брент стали менеджерами этих двух команд.

В это время мы снова достигли своих целей в феврале.

 

На самом деле, мы предоставили определенную услугу для Video.me. Встроили функцию CDN и предоставили целый кластер услуг, который позволял хранить контент. В теории мы распределили эти кластеры географически по всему миру и делали то, что делает CDN. Это доставка контента ближе к вашим заказчикам, клиентам.

Как вы можете видеть, инновация заключалась в том, что мы начали работать на этапе раннего принятия, интегрировали многие функции. Люди нас заметили, заметили наши продукты. Мы предоставили целую систему услуг, и качество было важно. Если бы мы не смогли с этим справиться… Качество здесь один из самых важных вопросов. Мы быстро адаптировали свои продукты.

К концу 2010 года наша команда начала расти. Пригласили еще двух разработчиков и еще одного специалиста по качеству.

Мы стали заниматься в большей степени адаптацией. Но наша миссия к тому моменту изменилась.

Мы хотели сфокусироваться на том, чтобы найти место, где есть множество клиентов, которые нуждаются в таких услугах. Сначала у нас были внутренние клиенты. Они говорили о том, что им необходимы эти функции.

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

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

А это те виды технологий, которые мы используем сегодня.

Я не буду подробно рассказывать, как мы их используем. MySQL, Cassandra, Hadoop and Hive, множество разных платформ тестирования качества. Web Load для тестирования. Вы сами видите на экране, что мы используем. Есть специальная программа, которая занята исключительно операциями. Мы построили свою собственную систему. Эрик, один из членов нашей команды, работал с программой Puppet.

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

Сейчас наша компания хорошо известна по всему миру. Мы предлагаем свои услуги не только внутренним клиентам: мы работаем в США, Амстердаме и Сингапуре. Сегодня в нашей команде задействовано больше ста серверов. Наши планы – расширяться.

Наш портфель продуктов.

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

Итак, как сработалась команда такого размера? Кто-то может сказать, что команда огромна. Но мы смотрим на конкурентов. Например, компания Big Daddy в Канаде предлагает решение для хранения данных в большом хранилище данных. В МС, например, около 200 человек, которые занимаются разработкой продуктов. Наша команда гораздо меньше. Cloud Storage предлагают продукты, а там всего 10 человек работает.

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

Изначально мы пытались использовать Scrum. Но он работал не очень хорошо. Пробовали в 2009 году. 

Для Kanban на тот момент не было хороших инструментов. Мы сделали очень простые приложения, расширения. Разработали собственный инструмент.

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

Мы работали для компании Toyota, для ее системы производства. Программа использовалась Microsoft. Эта книга рассказывает о том, на чем основан наш процесс, и каковы наши основные инструменты.

Итак, что такое Kanban в нашем варианте?

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

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

Card Wall – это колонки. Поток идет слева направо. Можно использовать и такие вещи.

Вы двигаетесь слева направо, в естественном порядке.

Что еще было важно?

Вот эта последовательность – от одного до шести. От самого простого к самому сложному. Итак, это рецепт успеха. Я еще раз к нему вернусь чуть позже.

Если у меня мало времени, то я это пропущу. Если есть время, то буду продолжать.

Итак, сконцентрируемся на качестве сокращения WIP. Наиболее важны первые четыре шага, на которых мы, в основном, концентрировались в нашей команде. Если вы делаете их обычной практикой, то добиваетесь успеха. Я видел множество команд, которые начинали с шагов "пять" и "шесть" – с приоритетов. Иногда это можно делать, но все-таки это будет непоследовательно. Если вы занимаетесь приоритезацией, а у вас нет высокого качества, вы просто зря тратите время.

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

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

Мы, прежде всего, полностью автоматизировали процесс. Периодически производим просмотры, переоценки. Облегчили интеграцию. Касательно этапа обзоров или пересмотров: здесь мы вводим четыре различных этапа. Потенциально это дает возможность привлечь несколько сотрудников к тому, чтобы они рассматривали одновременно эти маленькие истории (или "small stories", как это звучит по-английски).

Открытые коммуникации очень важны.

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

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

Происходит снижение объема работы, которая находится в разработке. Нас постоянно что-то отвлекает. Вы видите – здесь приходится одновременно делать массу дел.

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

Здесь вы видите, что в колонках вводятся воедино визуальные индикаторы того, что надо сделать, что делается, и так далее. Когда вы анализируете ситуацию вот в таком виде, очень просто выяснить, где проблемы, и подумать о том, где их источник.

Итак, 4 правила команд. Во-первых, создание малых историй. Это поток, который занимает пять дней. Сканирование происходит справа налево. Выбор этих историй… Слева направо – идентификация проблем. Таким образом происходит выяснение тех пунктов, которые надо поправить. Далее идет выработка плана – того, что надо сделать.

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

Необходимо разговаривать с людьми. Надо спрашивать: "Почему вы блокировали вот этот пункт?" Может быть, здесь не был сделан какой-то конкретный тест. Тогда вы как разработчик можете помочь. Может быть, вы выясните, что какой-то инструмент просто не комфортен для человека. Тогда вы, опять-таки, предлагаете какую-то помощь.

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

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

Надо создавать отношения доверия в рамках организации, с вашими партнерами, заинтересованными сторонами как на одном уровне с вами, так и на вышестоящем уровне.

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

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

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

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

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

Когда вы говорите: "Я слишком занят, не могу вам помочь, не могу заниматься какими-то еще делами, мне некогда дышать", - вы оказываетесь именно в такой ситуации.

Как решить эту проблему? Если вы создаете продукт высокого качества, то обратите внимание на то, чтобы снижать объем работы, который падает на каждого сотрудника – это позволит обеспечивать большую успешность работы всего коллектива, повысит результативность работы каждого. Это будет чем-то вроде волшебной палочки, которая расставит все по своим местам.

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

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

С другой стороны, иногда необходимо, чтобы появились какие-то идеи. Нужно время, чтобы подумать. Иногда руководство начинает требовать, чтобы сотрудники были активно заняты все время. А когда же им думать, заниматься генерацией идей? Это тоже надо предусмотреть. Но, с другой стороны, нельзя позволять сотрудникам спать за столом.

Руководство не одобряет наличия свободного времени у сотрудников. Оно боится, что люди будут спать. Можно придумать в качестве "переменки" какое-то несложное задание. Например, устроить перерыв и сказать: "Приберись на столе". Можно что-то поправить и починить своими руками, и так далее. Вы прекрасно понимаете, что, как в любой технической системе, люди не разбирающиеся могут очень долго ремонтировать какую-то небольшую поломку. А разбирающемуся человеку достаточно подкрутить несколько гаек, и все будет налажено.

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

Приоритезация очень важна. Приоритет, конечно, определяется представителями бизнеса, а не разработчиками. Ваш заказчик говорит: "У меня такие-то и такие-то приоритеты. Давайте сконцентрируем наше внимание на этом". Именно на это мы и должны ориентироваться. Если заказчик хочет установить пятидневный цикл в производстве, мы должны ориентироваться именно на этот цикл. Конечно, в такой ситуации бывает достаточно много неопределенностей. Надо постоянно пытаться их разрешить.

Год назад я участвовал в аналогичной конференции. После этой конференции я сказал коллеге: "Вопрос разработки качества – это вопрос, который отошел в прошлое. Сейчас это концепция, которая больше никого не интересует. Сейчас мы должны развивать другой подход – подход, который не признает ролей. Подход, при котором каждый сотрудник может заниматься чем угодно". Здесь обозначены наши сотрудники, которые занимались качеством.

Что же произошло после того нашего разговора, когда мы решили пересмотреть наш подход? Ранее эти люди занимались написанием автоматических тестов для проверки качества. Но мы подумали, что, в общем-то, этим может заниматься каждый в компании, или кто-то один может писать эти тесты качества, а все остальные могут быть разработчиками. Вы видите – теперь у нас все разработчики. Мы внедрили инструменты Oracle и считаем, что все наши сотрудники должны быть в состоянии с ними работать.

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

Здесь, как вы видите, все взаимосвязано. Все это у нас завязывается на кнопочку "easy" ("легкий пуск"). Все запускается из операционного центра. Создание, размещение, тестирование – все это делается быстрее.

Мы используем Jenkins, Puppet Labs. Вы видите взаимодействие между всеми этими системами.

Например, на Puppet Labs происходит обновление информации. Потом эта информация через центр поступает на тестирование. Все это завязано на кнопку "легкого пуска" – кнопку "easy". Разные кусочки этого "пазла" должны соединяться в одну целостную картинку. Соединяя их в одну картинку, мы можем получить комплексное управление процессом и его понимание. Именно этим мы занимались последние несколько месяцев.

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

В заключение хочу сказать вам о нашей миссии.

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

Фокус на качество. Качество – это работа каждого. Это очень важно. Каждый в нашей маленькой команде это осознает. Поэтому мы сейчас работаем без стены, которая отгораживает разработчиков от специалистов по качеству. У нас нет ситуации, когда разработчики сделали продукт, передали его отделу качества и говорят: "Теперь вы проверяйте качество". Нет. Мы работаем все вместе.

Конечно, важны такие вещи, как автоматизация, обзор, коммуникация. Автоматизация позволяет облегчать процессы, ускорять их. Обзор процессов – это чрезвычайно важный момент подведения итогов на определенном этапе. Коммуникация, общение – это момент, когда мы, опять-таки, можем поделиться друг с другом информацией, мнениями и так далее.

Надо снижать ваш WIP. Это очень важно, потому что это позволяет нам сконцентрироваться на главных аспектах деятельности. Объем текущей работы, который приходится на каждого сотрудника, должен быть разумным. Если вы стараетесь чаще выдавать готовый продукт, сформированный согласно более мелким задачам, и вносите этим вклад в общий процесс, это позволяет "оживить" процесс, сделать его более продуктивным и быстрым.

Надо быть готовым к эволюции, изменениям. Есть некоторые факторы, которые вы воспринимаете как известные или не известные, когда вы должны оценивать неопределенность и пытаться превратить ее в определенность.

Конечно, культура может меняться со временем. Мы видим постоянные изменения в культуре нашей компании применительно к продуктам и процессам. Мы считаем, что такой подход полезен. Внедрение новых процессов чрезвычайно плодотворно, потому что оно направлено на достижение нашей конечной цели.

На этом все, я хочу поблагодарить вас за внимание. Это все, что я хотел вам рассказать. Большое спасибо. Я был очень рад выступить перед вами. Надеюсь, когда-нибудь я смогу приехать и рассказать о том, что мы смогли дальше сделать с нашим подходом, не признающим ролей. Спасибо.

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Елена Глухова

Елена Глухова

Руководитель группы общих интерфейсов в Симферополе, Яндекс.

Специалисты "Яндекса" о разработке сложной кнопки, полностью повторяющей свойства и функциональность нативного браузерного элемента управления.

Евгения Фирсова

Евгения Фирсова

Руководитель отдела веб-интерфейсов, Яндекс.Деньги.

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

Георгий Баркан

Георгий Баркан

Руководитель разработки технологической стратегии развития пользовательских продуктов «Лаборатории Касперского».

Рассказ об управлении продуктом с точки зрения успеха этого процесса.