Так это надо было сразу в Disclaimer писать, тут другие правила нужны, так как обычный индус спорить с начальством не привык, даже если он не собирается выполнять его приказы.
Есть и четвертый путь — адаптировать code style под команду, обсуждая каждый пункт. Все 3 указанные Вами пути по сути являются авторитарным видом управления. Он работает, когда у Вас есть заслуженный авторитет в команде и большинство решений являются верными. Часто приводит к большой текучке в команде и снижению общей продуктивности.
Руками тестировать не дольше, более того, в большинстве случаев именно так и просходит разработка кода, если это не TDD. В некоторых случаях тесты могут сильно сократить время тестирования руками, например, когда разрабатывается какой-то алгоритм, преобразование данных, независимая библиотека. Но такого в большинстве коммерческих продуктов — не так много.
Джуну надо объяснять, для чего это нужно и важно, а если 90% его игнорируют, то может руководство — не Ваша сильная сторона и нужно немного поучиться или заняться другим? Впрочем, бывают очень жесткие code style из сотни пунктов, понятно, что адекватные люди его будут саботировать.
Ну Вы нашли, во что верить — в SLA!
Если уж так критичен простой, то нужно отдельный договор заключать с провайдером услуг, там все прописывать, а не надеяться на «авось».
При показателях от 98% и выше, любое падение — событие на грани статистической погрешности.
Автор что-то путает. 98% uptime означает, что незапланированный простой за год работы может составить более 7(СЕМИ) дней!
Рабочее оборудование и коннект либо есть, либо их нет.
То есть вариант того, что оборудование или коннект работает не стабильно не рассматривается?
Вы можете годами пользоваться хостером с показателем «надежности» в 50% (согласно его же SLA) без единой проблемы или «падать» раз в месяц на пару дней у ребят, где заявлено 99,99%.
SLA регламентирует, что клиент получает в случае простоя, а не гарантирует, что-то. Обычно ожидаемый uptime рассчитывается по прошлому периоду, но не совсем честные организации могут писать недостоверные цифры, а по SLA компенсировать какую-то незначительную долю ежемесячного платежа.
Если ваша проблема возникла по причине третьей стороны (на магистрали), то вроде как «никто не виноват» и когда решится проблема — вопрос вашей удачливости.
SLA — это все же добровольные намерения компании, она может вполне прописать, что действия 3-х лиц не покрываются SLA. Но на этот счет есть суд, через него вполне можно взыскать уплаченное за период простоя, а иногда и убытки, если удастся их доказать.
Например, при необходимости распределенной инфраструктуры (часть серверов в РФ, вторая — в ЕС), проще и выгоднее будет воспользоваться услугами хостеров, имеющих партнерские отношения с европейскими ДЦ по модели White Label.
Какой-то странный совет, какая разница, связан ли хостер в РФ с хостером ЕС или нет? Партнерские отношения ни к чему не обязывают и ничего не гарантируют.
Спасибо за пояснение, я бы предложил даже про Культ Карго рассказывать в самом начале обучения программированию и другим it-направлениям, может тогда будет меньше его последователей :)
В долгосрочном смысла не больше, поверьте. В любой момент к Вам подселят ресурсоемкого соседа и производительность Вашей VPS драматически просядет. Или наоборот, отселят и производительность увеличится. Смысл данной статьи в том, что все VPS, несмотря на сравнимую цену, могут по производительности отличаться в разы и даже на порядки.
Сразу стоит заметить, что характеристики виртуальных серверов отличаются друг от друга, а производительность, измеренная в определенный момент времени, является весьма относительной величиной, зависящей от нагрузки на ноду или канал, количества клиентов на ноде, времени суток, средней температуры на Марсе в сезон дождей и так далее, так что материал является скорее развлекательным.
Слишком мало подробностей про эту систему, к сожалению. А учитывая, что правительства некоторых стран(например, Франции) уже высказались про то, что будут блокировать Libra, так как они расценивают это как посягательство на монетарный суверенитет страны. Так что будущее Libra вообще под вопросом и в каком виде они ее запустят — не знает сейчас никто. Может и не запустят вообще.
Тестирование — это конечно, хорошо, но так как VPS живет в shared environment, показатели будут сильно зависеть от соседей. Автор об этом упомянул, но такое ощущение, что комментаторы это постоянно упускают из внимания.
Agile не имеет никакого отношения позицииям DevOps или DBA, это просто разные сущности.
С тех пор, как популярность монструозных DB типа Oracle сходит на нет, разработчики используют DB просто, чтобы хранить там данные, а для этого выделенный DBA не нужен. Обычно, один из backend-разработчиков или DevOps занимается проблемами базы. Например, когда стало не хватать производительности, это решается не очень сложно в mysql/postgres/mongodb — смотрим медленные запросы, добавляем ключи или меняем стуктуру хранения или берем более мощное железо. Проблему пофиксили — DB дальше живет сама по себе до следующих проблем. Если в команде квалификации не хватило — всегда можно привлечь сторонних консультантов, которые решат проблему. Это выгодней, чем иметь выделенного DBA.
Современный подход по хранению данных без схем(mongodb, json в mysql и postgres) позволяет избежать многих проблем при добавлении сотен новых полей что еще дальше откладывает потребность в DBA для проекта.
Те позиции, которые Вы назвали — узкоспециализированные, они нередко встречаются в крупных компаниях, особенно, которые давно на рынке. Сейчас компании берут просто DevOps, который и релиз может подготовить для разных ОС/девайсов/требований, мониторинг настроить и с Cloud Environments на ты. Эпоха dba уходит в прошлое по-тихоньку, так как монструозные базы оракла все менее популярны и хранение кода в процедурах DB считается неудобным подходом, а с остальным и DevOps справится.
DevOps — некоторая разновидность Шивы, соглашусь, но человек весьма уважаемый в коллективе, так как Cloud Environments становятся все сложнее и мощнее с каждым годом.
DevOps Engineer — устоявшаяся позиция зарубежом. По факту — член команды разработки, поэтому знает всю нутрянку и как оно работает и может расписать инфраструктуру на соответствующей технологии — Puppet, Terraform etc. Как отдельная позиция, нужен только когда много работы и команда уже немаленькая — десятки разработчиков. Впрочем, ничто не мешает взять админа и обучить его тому же самому )).
Мне трудно представить эффективную команду, где 10 разработчиков не пересекаются. Что будет, если кто-то заболеет или уйдет в отпуск?
Как раз это в разы дороже, чем на выделенном сервере, если, конечно, не Hello World разворачивать. То, что удобно — соглашусь.
Вот сколько я коммерческих проектов не видел, ни в одном не было даже близко 100% покрытия.
В чем немыслимость, компоненты без unit-тестов невозможно создать или сопровождать?
Если уж так критичен простой, то нужно отдельный договор заключать с провайдером услуг, там все прописывать, а не надеяться на «авось».
Автор что-то путает. 98% uptime означает, что незапланированный простой за год работы может составить более 7(СЕМИ) дней!
То есть вариант того, что оборудование или коннект работает не стабильно не рассматривается?
SLA регламентирует, что клиент получает в случае простоя, а не гарантирует, что-то. Обычно ожидаемый uptime рассчитывается по прошлому периоду, но не совсем честные организации могут писать недостоверные цифры, а по SLA компенсировать какую-то незначительную долю ежемесячного платежа.
SLA — это все же добровольные намерения компании, она может вполне прописать, что действия 3-х лиц не покрываются SLA. Но на этот счет есть суд, через него вполне можно взыскать уплаченное за период простоя, а иногда и убытки, если удастся их доказать.
Какой-то странный совет, какая разница, связан ли хостер в РФ с хостером ЕС или нет? Партнерские отношения ни к чему не обязывают и ничего не гарантируют.
Ваш Кэп.
С тех пор, как популярность монструозных DB типа Oracle сходит на нет, разработчики используют DB просто, чтобы хранить там данные, а для этого выделенный DBA не нужен. Обычно, один из backend-разработчиков или DevOps занимается проблемами базы. Например, когда стало не хватать производительности, это решается не очень сложно в mysql/postgres/mongodb — смотрим медленные запросы, добавляем ключи или меняем стуктуру хранения или берем более мощное железо. Проблему пофиксили — DB дальше живет сама по себе до следующих проблем. Если в команде квалификации не хватило — всегда можно привлечь сторонних консультантов, которые решат проблему. Это выгодней, чем иметь выделенного DBA.
Современный подход по хранению данных без схем(mongodb, json в mysql и postgres) позволяет избежать многих проблем при добавлении сотен новых полей что еще дальше откладывает потребность в DBA для проекта.
DevOps-инженер: «Я против такого понятия, как СТО БюроБюро»
DevOps — некоторая разновидность Шивы, соглашусь, но человек весьма уважаемый в коллективе, так как Cloud Environments становятся все сложнее и мощнее с каждым годом.