На самом деле не из-за незнания, а из-за нежелания сотрудничать и отсутствие общего руководства, понимающего что происходит и способного настучать по шапке. Того самого собственника системы.
P.S. я своими глазами видел не раз, как мелкое изменение внутреннего интерфейса рушит верстку внешнего. Например из-за неожиданно общих библиотек. Но это скорее вопрос уже к тестированию:-)
— чем больше было сделано релизов, тем ближе фактический результат проекта к ожидаемому.
Или чем качественнее был проработан способ достижения этого результата изначально, т.е. чем ближе к изначальной цели была каждая попытка. Вы говорите про итерационный метод, я — про качество изначальной проработки итерации. Естественно в жизни к хорошему результату приведут только оба пути одновременно, с первого раза всегда на 100% попадать не получится. Каждая неудавшаяся попытка это либо вред, либо недополученная польза, т.е. при итерационном методе всё равно time-to-market большой, просто по тому, что определиться он завершением работы над фичей, а не выводом в продуктив первой попытки. На анализ в любом случае будет потрачено время, только при итерационном методе тратится время еще и на переделки. Я не говорю, что не надо пробовать. Я говорю, что грамотный аналитик способен предсказать результат очень большого количества попыток. А грамотный энтерпрайз архитектор способен построить систему так, и в первую очередь я про бизнес-процесс, что бы по результатам вывода в продуктив первой же версии фичи потребовались лишь незначительные исправления и доработки логики. В большинстве случаев это в итоге получится быстрее и дешевле. В большинстве случаев итерационный метод скатывается к бессистемному тыканию пальцем в небо, так же как в вашем примере Waterfall скатывается к бюрократии.
Что же касается процесса и единого собственника, то такая орг. структура фактически сводит на нет наличие этого собственника системы. Комментарий чуть выше это очень наглядно показывает — кто то из заказчиков пришел к Вам, а не к собственнику системы. Это делает фигуру собственника совершенно номинальной. По хорошему, должно быть совсем наоборот, это собственник должен бегать за пользователями и выяснять их потребности. Находиться с ними в контакте.
На самом деле, то о чем Вы говорите, это как раз НЕ налаженный процесс. Я работал в подобных организациях. Обычно такое происходит когда:
а) нет единого собственника системы,
б) процессы построены ITSM теоретиками, ни разу в жизни не участвовавшими в реальной работе регламентируемого процесса.
И вот когда оба фактора объединяются — некие абстрактные «идеальные» процессы начинают считаться священной коровой, человека, который был бы заинтересован в нормальной работе, между эксплуатацией и разработкой просто нет, получается всякая разная фигня. А разруливать её некому.
Суть хороших процессов в том, что бы все происходило быстро и предсказуемо, что бы не забывать ничего важного и не изобретать один и тот же велосипед по нескольку раз в день, а не в сборе подписей в листе согласования.
Вот именно об этой позиции я и говорил выше в описании подмены понятий. Разработка это не программисты, а «опсы» это не админы. Взгляните на это, как на процессы создания и дальнейшего обслуживания. В обоих процессах будут участвовать как dev, так и ops, практически всегда. Инфраструктуру не dev'ы готовят, баги не админы исправляют.
Что касается затрат всё не так линейно. Процессы эксплуатации и разработки принципиально разные. Разработка последовательная, итерационная. Эксплуатация же на 80% реакция на случайные события. Задачи сами сильно разнятся. Эффективность в разделении заключается не в цене специалиста, оклады программистов и админов различается не сильнее, чем оклады программистов на разных языках, эффективность достигается за счет специализации и разделения процессов. Что бы все свои задачи решали в оптимальном режиме. Эксплуатация обычно дешевле в месяц за счет объема работы и количества сотрудников.
Документацию на любую разрабатываемую систему, не важно ИТ, или дом, всегда изначально пишет разработчик, а не обслуживающая компания, это проектная документация. Далее те, кто занимается обслуживанием, пишут уже свою, по реальной ситуации. И писать эту документацию должны не программисты, а аналитики, архитекторы, и технические писатели.
Ну я всё-таки не разработчик и смотрю со стороны на то, как это внедряют в реальной жизни. Есть там общая цель — прекрасный продукт. Беда именно в том, что эту цель трактуют по-разному. И DevOps, где в первую очередь оно Dev, трактуют её исходя из своей системы ценностей. А у Ops она принципиально другая, о чем я и писал. И подружить одно с другим на низком уровне не получится. Надо подниматься выше, на уровень управления продуктом в целом, и там принимать взвешенные решения исходя из стратегии развития, внимательно выслушивая обе стороны. Этим должен заниматься человек с техническим прошлым как минимум. Не видел еще ни одного бизнесс-заказчика, который бы понимал важность и последствия тех или иных технических решений. Т.е. управлять конфликтом, балансируя интересы сторон на благо продукта и объясняя почему было решено именно так.
Конечно неопределенность будет. Но от тщательности проработки идеи будет напрямую зависеть объем и срочность корректировок. Либо мы будем находиться в процессе постоянного переделывания, либо в процессе сделали, посмотрели, немного подправили. Переделываем только в особых случаях.
Нужно провести исследование спроса, проанализировать результаты, конкурентные предложения. Это работа для системного аналитика и опять же энтерпрайз архитектора. Промах, конечно, будет в любом случае — но вот его масштаб и глубина последствий при правильно проведенной аналитической работе значительно мньше и не столь критичны, чем В случае тыкания пальцем в небо. А значит, можно будет не спешить с корректировкой и колличество итераций будет существенно меньше. Хороший план, опять же, всегда будет иметь запас на корректировки;-)
Это значит, развивать продукт по плану, который не потребуется переделывать каждые пару дней. Когда этот план продуман и проработан, базируется на анализе рынка и поведения пользователей. Когда фичи в подавляющем большинстве случаев попадают в точку. Тогда количество внезапных изменений будет сведено к разумному минимуму.
P.S. То, что Вы описываете — это и есть функционал энтерпрайз-архитектора. И да, делать надо именно так, о чем я писал выше:-)
В принципе, мы пишем об этом в статье, когда говорим о дополнительной нагрузке. По моему опыту (может мне везло) я встречал людей, которым интересны их прямые обязанности и неинтересно напрягаться для других, особенно когда своих проблем хватает. В вашем примере с инструментом было бы здорово найти DevOps инженера, который тащится от помощи разработчикам в поиске и установке инструментов, тогда конфликт на этой стадии исчезнет. Но появится конфликт с эксплуатацией, которой придется напрягаться, чтобы с этим инструментом работать.
Проблема то ли в контроллере шины, то ли в контроллере на самой карте, точно сейчас не подскажу. Аппаратную спеку Citrix не светят (ну или я плохо искал), находили устройства по выводам dmesg и, вроде бы lspci там работает, дальше по спекам на найденные контроллеры. Но это было уже почти год назад, к сожалению не сохранили скриншоты…
Вайтлист работает по исходящим IP адресам. Мы пробрасываем серую сетку в l3 от клиента до нас и ее адреса добавляем вайтлист. Кстати, об этом будет в следующей статье :)
«Гартнер ранее говорил о проблемах производительности nas надстройки и далекой от 100 процентах совместимости api, тк новые фишки в родном s3 появляются ранее. Так ли это все?» NAS надстройка действительно тормозит, мы её поэтому и не используем. Совместимость реализуется действительно по догоняющему принципу, иначе никак. Но реализуется. Задержка конечно есть, складывается из реакции Cloudian и потом нашего обновления. Но она и в SDK будет.
«В родном s3 обьекты обьемом менее 128кб округляются вроде биллингом до 128, тут так же?» Нет, тут округляется до килобайта т.е. по сути не округляется. То же касается и стоимости запросов — 10001 запрос это именно 10001 запрос.
«Вроде в консоли есть возможность задать secondary/backup puppet master узел, в случае сбоя он корректно не переключается сам?» Конфигурация от Cloudian предполагает ручное переключение. Собственно все это счастье поставляется одним большим бинарём-инсталятором и дальше оно само разворачивает через мастер. Мы руками в конфигурации, в таких ситуациях, без критической необходимости не лазаем, что бы не отхватывать проблем лишних при обновлениях.
«Раскидывая новые узлы по новым рекам, rack awareness корректно работает при достаточном числе узлов?» Такого эксперимента не проводили, у нас же всего 4 ноды. Такую конфигурацию тащить на несколько стоек большого смысла нет.
«Расскажите как реализованы white list на сетевом уровне, чтобы трафик не тарифицировался, если например работа в рамках ЦОДа, а не по интернету.» Мы не сетевым оборудованием его биллим, а встроенным в Cloudian биллингом. Там есть возможность привязать white list к конкретному тарифному плану. Собственно по просьбе клиента мы можем это организовать, если используется выделенный под клиента линк до хранилища.
Спасибо за вопрос!
Честно говоря на свифт не смотрели по ряду причин, а так мы относимся к инфраструктурным провайдерам, а не к разработчикам ПО. У нас что-то такое допиливать нет ни возможности, ни желания.
Может и допилили, но для меня любой встроенный мониторинг обычно так и выглядит. :) На самом деле, ситуация близка к отраслевому стандарту, мониторинг есть, но для галочки. Мы используем свой отдельный мониторинг.
P.S. я своими глазами видел не раз, как мелкое изменение внутреннего интерфейса рушит верстку внешнего. Например из-за неожиданно общих библиотек. Но это скорее вопрос уже к тестированию:-)
Или чем качественнее был проработан способ достижения этого результата изначально, т.е. чем ближе к изначальной цели была каждая попытка. Вы говорите про итерационный метод, я — про качество изначальной проработки итерации. Естественно в жизни к хорошему результату приведут только оба пути одновременно, с первого раза всегда на 100% попадать не получится. Каждая неудавшаяся попытка это либо вред, либо недополученная польза, т.е. при итерационном методе всё равно time-to-market большой, просто по тому, что определиться он завершением работы над фичей, а не выводом в продуктив первой попытки. На анализ в любом случае будет потрачено время, только при итерационном методе тратится время еще и на переделки. Я не говорю, что не надо пробовать. Я говорю, что грамотный аналитик способен предсказать результат очень большого количества попыток. А грамотный энтерпрайз архитектор способен построить систему так, и в первую очередь я про бизнес-процесс, что бы по результатам вывода в продуктив первой же версии фичи потребовались лишь незначительные исправления и доработки логики. В большинстве случаев это в итоге получится быстрее и дешевле. В большинстве случаев итерационный метод скатывается к бессистемному тыканию пальцем в небо, так же как в вашем примере Waterfall скатывается к бюрократии.
Что же касается процесса и единого собственника, то такая орг. структура фактически сводит на нет наличие этого собственника системы. Комментарий чуть выше это очень наглядно показывает — кто то из заказчиков пришел к Вам, а не к собственнику системы. Это делает фигуру собственника совершенно номинальной. По хорошему, должно быть совсем наоборот, это собственник должен бегать за пользователями и выяснять их потребности. Находиться с ними в контакте.
а) нет единого собственника системы,
б) процессы построены ITSM теоретиками, ни разу в жизни не участвовавшими в реальной работе регламентируемого процесса.
И вот когда оба фактора объединяются — некие абстрактные «идеальные» процессы начинают считаться священной коровой, человека, который был бы заинтересован в нормальной работе, между эксплуатацией и разработкой просто нет, получается всякая разная фигня. А разруливать её некому.
Суть хороших процессов в том, что бы все происходило быстро и предсказуемо, что бы не забывать ничего важного и не изобретать один и тот же велосипед по нескольку раз в день, а не в сборе подписей в листе согласования.
Что касается затрат всё не так линейно. Процессы эксплуатации и разработки принципиально разные. Разработка последовательная, итерационная. Эксплуатация же на 80% реакция на случайные события. Задачи сами сильно разнятся. Эффективность в разделении заключается не в цене специалиста, оклады программистов и админов различается не сильнее, чем оклады программистов на разных языках, эффективность достигается за счет специализации и разделения процессов. Что бы все свои задачи решали в оптимальном режиме. Эксплуатация обычно дешевле в месяц за счет объема работы и количества сотрудников.
Документацию на любую разрабатываемую систему, не важно ИТ, или дом, всегда изначально пишет разработчик, а не обслуживающая компания, это проектная документация. Далее те, кто занимается обслуживанием, пишут уже свою, по реальной ситуации. И писать эту документацию должны не программисты, а аналитики, архитекторы, и технические писатели.
Нужно провести исследование спроса, проанализировать результаты, конкурентные предложения. Это работа для системного аналитика и опять же энтерпрайз архитектора. Промах, конечно, будет в любом случае — но вот его масштаб и глубина последствий при правильно проведенной аналитической работе значительно мньше и не столь критичны, чем В случае тыкания пальцем в небо. А значит, можно будет не спешить с корректировкой и колличество итераций будет существенно меньше. Хороший план, опять же, всегда будет иметь запас на корректировки;-)
Я умышленно не стал об этом писать — SRE это то, чего не хватает эксплуатации, а мы все-таки про влияние процессов разработки:-)
Это значит, развивать продукт по плану, который не потребуется переделывать каждые пару дней. Когда этот план продуман и проработан, базируется на анализе рынка и поведения пользователей. Когда фичи в подавляющем большинстве случаев попадают в точку. Тогда количество внезапных изменений будет сведено к разумному минимуму.
P.S. То, что Вы описываете — это и есть функционал энтерпрайз-архитектора. И да, делать надо именно так, о чем я писал выше:-)
«Гартнер ранее говорил о проблемах производительности nas надстройки и далекой от 100 процентах совместимости api, тк новые фишки в родном s3 появляются ранее. Так ли это все?» NAS надстройка действительно тормозит, мы её поэтому и не используем. Совместимость реализуется действительно по догоняющему принципу, иначе никак. Но реализуется. Задержка конечно есть, складывается из реакции Cloudian и потом нашего обновления. Но она и в SDK будет.
«В родном s3 обьекты обьемом менее 128кб округляются вроде биллингом до 128, тут так же?» Нет, тут округляется до килобайта т.е. по сути не округляется. То же касается и стоимости запросов — 10001 запрос это именно 10001 запрос.
«Вроде в консоли есть возможность задать secondary/backup puppet master узел, в случае сбоя он корректно не переключается сам?» Конфигурация от Cloudian предполагает ручное переключение. Собственно все это счастье поставляется одним большим бинарём-инсталятором и дальше оно само разворачивает через мастер. Мы руками в конфигурации, в таких ситуациях, без критической необходимости не лазаем, что бы не отхватывать проблем лишних при обновлениях.
«Раскидывая новые узлы по новым рекам, rack awareness корректно работает при достаточном числе узлов?» Такого эксперимента не проводили, у нас же всего 4 ноды. Такую конфигурацию тащить на несколько стоек большого смысла нет.
«Расскажите как реализованы white list на сетевом уровне, чтобы трафик не тарифицировался, если например работа в рамках ЦОДа, а не по интернету.» Мы не сетевым оборудованием его биллим, а встроенным в Cloudian биллингом. Там есть возможность привязать white list к конкретному тарифному плану. Собственно по просьбе клиента мы можем это организовать, если используется выделенный под клиента линк до хранилища.
Честно говоря на свифт не смотрели по ряду причин, а так мы относимся к инфраструктурным провайдерам, а не к разработчикам ПО. У нас что-то такое допиливать нет ни возможности, ни желания.