Огниво-огнище просто. Теперь работать бухгалтером будет нельзя? Только скниго держателем". И торговать бюстгальтерами тоже, только "сисько держателями". Если, что слова типа "лампа" - тоже греческое. Я уже молчу про имена. Теперь тоже в документах можно будет упоминать, только Владиславов, да Владимиров. Да Фёклы с Полинами.
Конечно могут понадобиться другие сервисы. Поэтому и существует пирамида тестирования. Есть множество готовых сетов. Но каждая компания адаптирует под себя исходя из размера проекта, его степени зрелости и фазы, степени зрелости самой компании. В общем случаем - создал Feature/User Story, создал сабтаски на разработку обновлениями кода, на обновление документации, на написание тестов на всех уровнях - Unit, Unit Integration, Subsystem, Subsystem Integration, System, System Integration, Acceptance. Тут уже количество уровней напрую зависит от Архитектуры и должно коррелироваться ей, может продукту и 1го уровня достаточно. В сабтасках создаются feature branches, во все тесты просачивается tag с именем feature или любой другой идентификатор на усмотрение команды. Теперь, магия. Запуск тестов на всех уровнях с данным тагом покрывает весь необходимый функционал. Если же это не происходит, значит либо проблема с Архитектурой и документацией, что она не позволила сделать правильное решение какие тесты должны быть добавлены и обновлены, либо кто-то в команде не понимает, что происходит. Опять же теперь есть инструменты с AI позволяющие помочь с данной идентификацией. На сколько им доверять - это уже вопрос отдельный. Цепочка которую вы выбрали вполне себе может существовать. Но как раз она является проблемой. Это взгляд на продукт снизу вверх, индуктивный. При рассмотрении продукта снизу вверх невозможно увидеть связей. Для этого нужно смотреть сверху вниз как пользователь. Пользователя интересует чтобы вызов действия приводил к ожидаемым последствиям, а не то все как именно оно реализовано. И именно рассмотрение сверху вниз через Архитектуру дает быстрое понимание задействованных модулей и интерфейсов. Но опять же при условии, что они нормально и актуально задокументированы.
Я бы не сказал, что это сложно. Но это требует работы. Которую, с одной стороны делать нужно, а с другой стороны делать не хотят. И платить за нее не хотят. Это требует грамотного построения процеса и адекватной поддержки документации. Если задачи сгруппированы по features/user stories, залинкованы друг с другом согласно Software Architecture. Feature/user story включает позадачи не только на разработку но и на написание/обновление тестов на всех уровнях, поддержку документации, составление тест-плана, и т.д. То никаких проблем собрал release notes, тесты посмотрел по tags, эквивалентным фичам, можно парсить заколовок feature branch и брать оттуда, если ведется конвенция заголовок. Я ведь надеюсь она ведется, хотя бы для интеграции Task Management c репозиторием. И получаешь тест-ран без проблем в несколько кликов или вообще автоматизировано. Если в документацию не вкладываться, на Архитектуру и прочую документацию не обращать внимания, на планирование и согласование тестов время не выделять. И по менеджменту проекта только делать вид, а не реально оперировать тикетами, вести релиз менеджмент. То да, сделать эффективное тестирование - нереально. Тестирование, всегда опирается на входные данные в виде документации(требования, архитектуру, описание интерфейсов), если в это не вкладываться - тестирование не имеет смысла. Потому что задача тестирования, оценить степень готовности продукта и риск его релиза в текущем состоянии. А без входных данных невозможно измерить объем работ и изменений. И любой результат тест репорта - будет просто сферическим числом в вакууме. По которому абсолютно ничего нельзя сказать и измерить.
Они непосредственно связаны. Независимо от того приемник и получатель - это люди или технические приспособления. Главное правило - передавать информацию имеет смысл тогда и только тогда, когда приемник готов ее получить. Следующее - это использование понятных как передатчик так и приемнику форматов сообщений. Для техники это выражается в использовании API, RFC, форматов пакетов и заголовках. Люди тут мало чем отличаются. Нужно использовать понятный язык т в это понятие входит не только различие, например, русский и китайский. Но и терминалогия, стиль языка, формат изложения мыслей, используемые инструменты и удобство их использование не только для отправителя, но и для получателя. Как вы верно заметили, дисциплина из менеджмента о построении внутренних коммуникаций, всего лишь адаптирует более общие и абстрактные правила из предмета теории информации, который одинаковом применим к любой сфере, специально для сферы коммуникации людей в компаниях. Также я убежден что построение любой системы необходимо вести сверху-вниз. От общего к частному соответственно. Следовательно и для коммуникаций я убежден. Что для начала нужно понять общие правила передачи информации, и исходя из этого, их грамотно адаптировать для людских коммуникаций. А все попытки уходить от письменности - это исключительно сдвиг в сторону удобства 1го, отправителя, который зачастую менеджер и считает себя более важным, а свое время более дорогим. В сторону перекладывания трудо-затрат на восприятие и поиск информации получателя, которых обычно много больше. И сумарные затраты каждым получатель времени на поиск информации в видео и чатах съедает непропорционально много времени, а значит и денег компании. Если которотко, в данной системе менеджмент или руководство или любой другой контент мейкер делает видимость собственной производительности за счет, по-сути, воровства ресурсов компании, путем создания пузыря, поедающего время потребителей информации. Исходя из этого я убежден, что видео может служить дополнительным средство информации в очень ограниченной сфере. А перевод к видео-контенту за счет уменьшения текстовой информации - путь неверный. Поиск по тексту всегда будет быстрее поиска по видео. Структурирование текста, также имеет намного более продвинутые средства.
Когда начальный фреймворк написан плохо, всегда проблемы. Тестовые сценарии всегда должны быть отделены, чтобы как раз можно было перенести на новый фреймворк с минимальными усилиями. Но часто об этом не думают. И пришли к этому благодаря оутсорс. Проект сделал, как быстрее. Все работает, а про дальнейшую поддержку уже никто не думает. Скорее всего это будет проблема других команд, которые придут скажут как все плохо и будут полностью переделывать.
Для этого придуманы таги. Ставишь нужные таги исходя из архитектуры и потом запускаешь сьюты по тагам. Тут конечно нужно думать, архитектуру читать. А еще ее должен кто-то написать. А silver bullet - не существует. Хочу не думать и чтобы все за меня получилось. Так не бывает. Кто-то верит, что AI все сможет. Если готовы так рискнуть, можете его попробовать сейчас достаточно инструментов устраивают AI для этих целей. Строится интеграция с системами Тест Менеджмента, и AI за вас соберет необходимые сьюты.
Мрак, конечно. Я только не понял проблему с файлами и количеством тестов. Разве тесты не по Танцам в сьюты собираются? Какая разница сколько там в файле? Ну а вообще умные ожидания - это как бы база. Но в современных реалиях лучше сразу использовать асинхронный подход. А вообще, никто не пытается решить ключевую проблему. Как вы выбираете какие именно тесты будут гоняться для комитета? Никто не хочет думать и просто выбирает все тесты, что есть. Но в этом нет ни смысла, ни логики. Из всего количества в 95% случаев нужно прогнать только тесты связанные с затронутым функционалом. А остальная масса - просто пожирает время. Не неся в себе никакой информации. И так очевидно, что изменения, например админки или бэкофиса, никак не могут повлиять на процессинг платежей или MFA. Но в подавляющем большинстве тесты все равно будут запущены и результаты получены. Только как какой в этом толк. Начинать всегда нужно с правильных механик, что и когда запускать. На коммит - достаточно проверить непосредственный модуль и смежные. А полный прогон на merge feature branch. Это, конечно, не отменяет важности проделанных изменений. Но подход не с той стороны. Большую часть проблемы можно было решить гораздо меньшими усилиями.
А можно подробнее про видеопоток? А то я очень опечалился когда MS выкинули поддержку проброса видеокарт в виртуалку. FX что-то там называлась. Вот KVM - умеет. Ну и вообще, ниша когда контейнеры низа что не вытеснят виртуалки - это другие ОС и архитектуры. Ну не могут контейнеры сделать Arm на AMD64 и наоборот. Да и QNX на виде в контейнере не взлетает, как и на Linux.
Я вот не понимаю, чем оно лучше. Ответ один: "Виртуальные машины - безопасней чем контейнеры." Поэтому VirtualBox или Hyper-V, можно устанавлтвать и использовать. А docker - нет. А раз докер установить нельзя - остается оркестрация вокруг виртуалок. Т.е. Vagrant и Terraform. А еще это вечно веселое правило. Нельзя ничего устанавливать не из корпоративного приложения, но если оно работает просто из бинарника, то можно создать папку со специальным именем и запускать бинари оттуда. Да и Microsoft Store забывают блокировать, так что из него все равно устанавливается. Вот такая безопасность. Всем неудобно, зато дыры на каждом шагу. Судя по всему, ьезопасник просто ничего не слышал про Vagrant boxes. Вот и не возражает. Ну и тут получил бы я на сервере виртуалку в которой можно кубер развернуть и крутил бы сервисы как хотел. Но нет, на серверах только виртуалки, через LXC. Ну идоступа естественно к админе никто не даст. Поэтому хочешь память увеличить, добавить места, поправить настройки сети. Создавай тикет на каждый чих, и жди пока у админа время будет это сделать и не факт, что как нужно с первого раза.
Я не ставлю никакого знака равенства. Мне нужна возможность легко и быстро разворачивать окружение, ломать его, убивать, и снова разворачивать. С помощью контейнеров, я могу 1 раз собрать нужные образы, написать конфигурации и запускать. А еще с контейнерами не нужно заморачиваться с восстановлением баз и прочих данных, которые могут затронуть тесты. У контейнеров если не настроить persistent volume, то измененные данные умрут вместе с контейнером, что мне и нужно. В первом приближении, мне хватит и docker-compose. Но я вполне не против kubernetes - он еще облегчит проблему получения ключей TLS каждым сервисом. Но в любом варианте для начала необходимо установить docker и иметь docker container registry. А это все запрещено безопасниками - потому что: "контейнеры - это небезопасно". А итоге нужно городить все тоже самое, только через vagrant, использовать центральный box registry. Потому что Gitlab - docker registry умеет, а vagrant box registry - не умеет. Потом виртуалки сохраняют все данные и нужно прикручивать решения по очистке данных, восстановлению баз и т.д. Terraform - не умеет из коробки работать с сертификатами и ключами - нужно еще Vault подключать. В итоге Kubernetes окружения подключаются к Gitlab за день максимум. А вот без установленного docker. Поясните мне как быстренько подключить и управлять окружениями из gitlab? Чтобы через pipeline ими управлять. И да приложение использует сервисы на разных нодах с проверкой TLS.
Лично мне по большому счету все равно. Я могу и писать запросы на получение физического сервера и каждый раз устанавливать все руками и тратить на это месяцы времени. Но бизнес требует быстрее. CI/CD без контейнеров - не работает.
Всегда можно найти что и как делать. На одной стране свет клином не сошелся. Есть Грузия, Армения, Кипр, ОАЭ. Можно делать бизнес там. Налоги будут всяко меньше.
Я могу развернуть окружение для тестирования на Kubernetes за пару часов. Поддержка его займет вообще минуты. Но, контейнеры ведь нельзя. Поэтому и Kubernetes - нельзя. Своего хранилища образов нет. Что остается? Сесть и переписать все на Vagrant и или Terraform. Виртуалки то по-прежнему можно. Ну и получается тянем боксы с открытого репозитория. Здравствуй безопасность. Теряем время на переделывание всего. Теряем время на запуск. Контейнеры стартуют минут за 3-5. Окружение на виртуалках стартует минут за 40. Самостоятельная настройка tls сертификатов для виртуалок - тоже требует настройки, Vault - тоже сам прикрути. Или забей на все. Используй один пароль на все и отключи https. Какой вариант имеет больше шансов? Ну и плюс если нужно изменить настройки или что-то проверить в kubernetes, то сам же пошел и проверил. Если завязан на виртуалки, то сделал тикет и сиди жди пока до него кто-нибудь дойдет. Ты ждешь, рабочее время тикает.
Погодите. Тут ключевой вопрос. Тулинг для безопаснов не должен ограничиваться тулинг для всех остальных. Единственная действительная причина запретить инструмент всей компании в масштабах тысяч сотрудников - это доказана уязвимость в инструменте. Подход - мне сложно это проверять или мне не принесли нужны молоток - тут не уместен. Проблемы 1-10 безопасников не стоят того чтобы делать проблемы тысячам других людей, забирая у них инструменты которые ускоряют работу. Если контейнеры и Kubernetes снимают головную боль по ручной настройке и разворачиванию тестовых окружений, настройке сертификатов для tls, настройки паролей и ключей ssh. То безопасники должны придумать как предоставить всей компании сервис. А не говорить, нет нельзя контейнеры, копируйте ключи руками. Генерирует себя самоподписные сертификаты и вставляйте их везде где нужно. Это все приводит только к откату на обычный http, вместо https. И передаче единого палочки на все по чатам. Кому от этого лучше?
С таким товаром - нужны очень проверенные поставщики. Продажи - тоже вопрос специфический в этом сегменте. Я так понимаю стратегии не было никакой. Думаю было бы лучше расти очень медленно и на начальном этапе вообще вести бизнес в свободное от других дел время. Создать малый круг клиентов, и малый объем от проверенных поставщиков. И очень постепенно расти. Конечно пандемия подкосила многие бизнесы и то что не закрылись в нее - уже достижение. Меня конечно сейчас заплюют, но когда жене захотелось устриц поехали на соседний остров и набрали в море сами. Лень нырять, в киоске на берегу можно взять порцию 3-4 евро.
А вы можете какое-то обоснование дать законности и своим выводам? Я думаю мем про дань и современные налоги всем известен. Что Чингисхан охренел бы узнав что можно брать не 10-20%, а 50-60%. А главное мне очень интересно посмотреть обоснование таких ставок. Вот я считаю 10-20% обоснованными, а выше - нет. Лучше на зарплатах депутатов и прочих высокооплачиваемых воров, сэкономить остальное. Ой простите, т.е. конечно же очень уважаемых и нужных людей без которых стране никак не выжить.
Если смотреть на одну из ситуаций - то скорее всего так и будет. Если смотреть на все полеты в целом, то это должно быть полностью на компьютере. У пилота есть более важные задачи во время полета, чем считать деньги. Такая информация снижает когнитивные функции и отвлекает от более важной - состояния самолёта и окружающей среды.
Никогда такого не было и вот опять. Эти ситуации делятся на 2 типа. Как с телевизорами и прочими устройствами, где экономят на флешке и тестировании совместимости. Такое был она телевизорах Samsung и камерах, пока они не вырезали Скайп. Они даже не делали свои камеры, но телевизор понимал ограниченный ряд разных производителей, но только на одно единственном чипе, чей драйвер положили в прошивку. А другой случай, это вот Synology, когда компания ловит "свои" девайсы от жадности. Как картриджи для принтеров и прочие странные вещи. Но есть действительно проблемы производителей чипов. Например те же сетевые карты сейчас опять же весьма криво поддерживаются в Linux, особенно WiFi. Производители чипов кладут делать нормальные драйвера и открывать документацию для других. Поэтому использоваться ими в Линукс -- невозможно.
Выглядит немного, странно. Вы вообще смотрели теорию информации и построение внутренних коммуникаций? В чем современная проблема митингов? В том что менеджеры их используют для своего личного удобства, а не пользы компании. Как уже заметили выше можно просто посчитать, стоимость каждого митинга по ЗП. Но этого никто не делает. В больших компаниях, вроде Амазона, это все посчитано. Митинг просто так создать нельзя. Нужно писать объяснительную почему эти люди нужны. Это служит хорошим барьеров к чрезмерному росту ненужных митингов. А вообще, проблема митингов решается комплексным подходом к распространению информации в компании. Информация должна быть классифицирована, это во-первых. В зависимости от класса она должна быть передана устно, либо письменно. Потому что умная информация - это одноразово. Письменная - это навсегда и с большим удобством поиска и обработки. Голосовые сообщения - реально в работе никто не слушает и не будет. К тому же поиск по ним крайне сложный. Можно использовать ИИ для стенографии, но это все платно, а бизнес экономит. Поэтому когда делают записи видео для передачи информации - это зло в этих фильмах потом невозможно ничего найти и для того что в тексте можно найти за секунды, приходится тратить часы на повторные просмотры видеозаписей. Да и скопировать пару строк текста из видео это не тривиальная задача. Так что проблемы митингов, описаны и задокументированы и решаются вовсе не улучшениями инструментов для создания их большего количества и удобства.
Заставить информацию записывать.
Митинги без meeting notes - запретить.
Передавать информацию правильным путём. Критическую - только e-mail, быстрые вопросы - чат. brain storm - meeting с meeting notes.
Заставить сотрудников читать, всех, начиная с менеджеров. За вопрос без предварительной проверки в knowledge base - повторное прохождение тренинга по передаче информации внутри компании.
Когда компании начинают в политику - это встреча Титаника с айсбергом. Результаты будут видны в следующих сериях. Но шансы снова стать успешной стремительно тают.
Огниво-огнище просто. Теперь работать бухгалтером будет нельзя? Только скниго держателем". И торговать бюстгальтерами тоже, только "сисько держателями".
Если, что слова типа "лампа" - тоже греческое. Я уже молчу про имена. Теперь тоже в документах можно будет упоминать, только Владиславов, да Владимиров. Да Фёклы с Полинами.
Конечно могут понадобиться другие сервисы.
Поэтому и существует пирамида тестирования.
Есть множество готовых сетов. Но каждая компания адаптирует под себя исходя из размера проекта, его степени зрелости и фазы, степени зрелости самой компании.
В общем случаем - создал Feature/User Story, создал сабтаски на разработку обновлениями кода, на обновление документации, на написание тестов на всех уровнях - Unit, Unit Integration, Subsystem, Subsystem Integration, System, System Integration, Acceptance. Тут уже количество уровней напрую зависит от Архитектуры и должно коррелироваться ей, может продукту и 1го уровня достаточно.
В сабтасках создаются feature branches, во все тесты просачивается tag с именем feature или любой другой идентификатор на усмотрение команды.
Теперь, магия. Запуск тестов на всех уровнях с данным тагом покрывает весь необходимый функционал.
Если же это не происходит, значит либо проблема с Архитектурой и документацией, что она не позволила сделать правильное решение какие тесты должны быть добавлены и обновлены, либо кто-то в команде не понимает, что происходит.
Опять же теперь есть инструменты с AI позволяющие помочь с данной идентификацией. На сколько им доверять - это уже вопрос отдельный.
Цепочка которую вы выбрали вполне себе может существовать. Но как раз она является проблемой. Это взгляд на продукт снизу вверх, индуктивный. При рассмотрении продукта снизу вверх невозможно увидеть связей. Для этого нужно смотреть сверху вниз как пользователь. Пользователя интересует чтобы вызов действия приводил к ожидаемым последствиям, а не то все как именно оно реализовано. И именно рассмотрение сверху вниз через Архитектуру дает быстрое понимание задействованных модулей и интерфейсов. Но опять же при условии, что они нормально и актуально задокументированы.
Я бы не сказал, что это сложно. Но это требует работы. Которую, с одной стороны делать нужно, а с другой стороны делать не хотят. И платить за нее не хотят.
Это требует грамотного построения процеса и адекватной поддержки документации. Если задачи сгруппированы по features/user stories, залинкованы друг с другом согласно Software Architecture. Feature/user story включает позадачи не только на разработку но и на написание/обновление тестов на всех уровнях, поддержку документации, составление тест-плана, и т.д. То никаких проблем собрал release notes, тесты посмотрел по tags, эквивалентным фичам, можно парсить заколовок feature branch и брать оттуда, если ведется конвенция заголовок. Я ведь надеюсь она ведется, хотя бы для интеграции Task Management c репозиторием. И получаешь тест-ран без проблем в несколько кликов или вообще автоматизировано.
Если в документацию не вкладываться, на Архитектуру и прочую документацию не обращать внимания, на планирование и согласование тестов время не выделять. И по менеджменту проекта только делать вид, а не реально оперировать тикетами, вести релиз менеджмент. То да, сделать эффективное тестирование - нереально.
Тестирование, всегда опирается на входные данные в виде документации(требования, архитектуру, описание интерфейсов), если в это не вкладываться - тестирование не имеет смысла. Потому что задача тестирования, оценить степень готовности продукта и риск его релиза в текущем состоянии. А без входных данных невозможно измерить объем работ и изменений. И любой результат тест репорта - будет просто сферическим числом в вакууме. По которому абсолютно ничего нельзя сказать и измерить.
Они непосредственно связаны. Независимо от того приемник и получатель - это люди или технические приспособления.
Главное правило - передавать информацию имеет смысл тогда и только тогда, когда приемник готов ее получить.
Следующее - это использование понятных как передатчик так и приемнику форматов сообщений. Для техники это выражается в использовании API, RFC, форматов пакетов и заголовках. Люди тут мало чем отличаются. Нужно использовать понятный язык т в это понятие входит не только различие, например, русский и китайский. Но и терминалогия, стиль языка, формат изложения мыслей, используемые инструменты и удобство их использование не только для отправителя, но и для получателя.
Как вы верно заметили, дисциплина из менеджмента о построении внутренних коммуникаций, всего лишь адаптирует более общие и абстрактные правила из предмета теории информации, который одинаковом применим к любой сфере, специально для сферы коммуникации людей в компаниях.
Также я убежден что построение любой системы необходимо вести сверху-вниз. От общего к частному соответственно. Следовательно и для коммуникаций я убежден. Что для начала нужно понять общие правила передачи информации, и исходя из этого, их грамотно адаптировать для людских коммуникаций.
А все попытки уходить от письменности - это исключительно сдвиг в сторону удобства 1го, отправителя, который зачастую менеджер и считает себя более важным, а свое время более дорогим. В сторону перекладывания трудо-затрат на восприятие и поиск информации получателя, которых обычно много больше. И сумарные затраты каждым получатель времени на поиск информации в видео и чатах съедает непропорционально много времени, а значит и денег компании.
Если которотко, в данной системе менеджмент или руководство или любой другой контент мейкер делает видимость собственной производительности за счет, по-сути, воровства ресурсов компании, путем создания пузыря, поедающего время потребителей информации.
Исходя из этого я убежден, что видео может служить дополнительным средство информации в очень ограниченной сфере. А перевод к видео-контенту за счет уменьшения текстовой информации - путь неверный.
Поиск по тексту всегда будет быстрее поиска по видео. Структурирование текста, также имеет намного более продвинутые средства.
Когда начальный фреймворк написан плохо, всегда проблемы. Тестовые сценарии всегда должны быть отделены, чтобы как раз можно было перенести на новый фреймворк с минимальными усилиями.
Но часто об этом не думают. И пришли к этому благодаря оутсорс. Проект сделал, как быстрее. Все работает, а про дальнейшую поддержку уже никто не думает. Скорее всего это будет проблема других команд, которые придут скажут как все плохо и будут полностью переделывать.
Для этого придуманы таги.
Ставишь нужные таги исходя из архитектуры и потом запускаешь сьюты по тагам. Тут конечно нужно думать, архитектуру читать. А еще ее должен кто-то написать. А silver bullet - не существует. Хочу не думать и чтобы все за меня получилось. Так не бывает. Кто-то верит, что AI все сможет. Если готовы так рискнуть, можете его попробовать сейчас достаточно инструментов устраивают AI для этих целей. Строится интеграция с системами Тест Менеджмента, и AI за вас соберет необходимые сьюты.
Мрак, конечно.
Я только не понял проблему с файлами и количеством тестов. Разве тесты не по Танцам в сьюты собираются? Какая разница сколько там в файле?
Ну а вообще умные ожидания - это как бы база. Но в современных реалиях лучше сразу использовать асинхронный подход.
А вообще, никто не пытается решить ключевую проблему.
Как вы выбираете какие именно тесты будут гоняться для комитета?
Никто не хочет думать и просто выбирает все тесты, что есть. Но в этом нет ни смысла, ни логики. Из всего количества в 95% случаев нужно прогнать только тесты связанные с затронутым функционалом. А остальная масса - просто пожирает время. Не неся в себе никакой информации. И так очевидно, что изменения, например админки или бэкофиса, никак не могут повлиять на процессинг платежей или MFA. Но в подавляющем большинстве тесты все равно будут запущены и результаты получены. Только как какой в этом толк. Начинать всегда нужно с правильных механик, что и когда запускать. На коммит - достаточно проверить непосредственный модуль и смежные. А полный прогон на merge feature branch.
Это, конечно, не отменяет важности проделанных изменений. Но подход не с той стороны. Большую часть проблемы можно было решить гораздо меньшими усилиями.
А можно подробнее про видеопоток? А то я очень опечалился когда MS выкинули поддержку проброса видеокарт в виртуалку. FX что-то там называлась.
Вот KVM - умеет.
Ну и вообще, ниша когда контейнеры низа что не вытеснят виртуалки - это другие ОС и архитектуры. Ну не могут контейнеры сделать Arm на AMD64 и наоборот. Да и QNX на виде в контейнере не взлетает, как и на Linux.
Я вот не понимаю, чем оно лучше. Ответ один: "Виртуальные машины - безопасней чем контейнеры."
Поэтому VirtualBox или Hyper-V, можно устанавлтвать и использовать. А docker - нет. А раз докер установить нельзя - остается оркестрация вокруг виртуалок. Т.е. Vagrant и Terraform.
А еще это вечно веселое правило. Нельзя ничего устанавливать не из корпоративного приложения, но если оно работает просто из бинарника, то можно создать папку со специальным именем и запускать бинари оттуда.
Да и Microsoft Store забывают блокировать, так что из него все равно устанавливается.
Вот такая безопасность. Всем неудобно, зато дыры на каждом шагу.
Судя по всему, ьезопасник просто ничего не слышал про Vagrant boxes. Вот и не возражает.
Ну и тут получил бы я на сервере виртуалку в которой можно кубер развернуть и крутил бы сервисы как хотел. Но нет, на серверах только виртуалки, через LXC. Ну идоступа естественно к админе никто не даст.
Поэтому хочешь память увеличить, добавить места, поправить настройки сети. Создавай тикет на каждый чих, и жди пока у админа время будет это сделать и не факт, что как нужно с первого раза.
Я не ставлю никакого знака равенства.
Мне нужна возможность легко и быстро разворачивать окружение, ломать его, убивать, и снова разворачивать.
С помощью контейнеров, я могу 1 раз собрать нужные образы, написать конфигурации и запускать. А еще с контейнерами не нужно заморачиваться с восстановлением баз и прочих данных, которые могут затронуть тесты. У контейнеров если не настроить persistent volume, то измененные данные умрут вместе с контейнером, что мне и нужно.
В первом приближении, мне хватит и docker-compose. Но я вполне не против kubernetes - он еще облегчит проблему получения ключей TLS каждым сервисом. Но в любом варианте для начала необходимо установить docker и иметь docker container registry.
А это все запрещено безопасниками - потому что: "контейнеры - это небезопасно".
А итоге нужно городить все тоже самое, только через vagrant, использовать центральный box registry. Потому что Gitlab - docker registry умеет, а vagrant box registry - не умеет. Потом виртуалки сохраняют все данные и нужно прикручивать решения по очистке данных, восстановлению баз и т.д. Terraform - не умеет из коробки работать с сертификатами и ключами - нужно еще Vault подключать. В итоге Kubernetes окружения подключаются к Gitlab за день максимум. А вот без установленного docker. Поясните мне как быстренько подключить и управлять окружениями из gitlab? Чтобы через pipeline ими управлять. И да приложение использует сервисы на разных нодах с проверкой TLS.
Лично мне по большому счету все равно. Я могу и писать запросы на получение физического сервера и каждый раз устанавливать все руками и тратить на это месяцы времени. Но бизнес требует быстрее. CI/CD без контейнеров - не работает.
Всегда можно найти что и как делать. На одной стране свет клином не сошелся. Есть Грузия, Армения, Кипр, ОАЭ. Можно делать бизнес там. Налоги будут всяко меньше.
Я могу развернуть окружение для тестирования на Kubernetes за пару часов. Поддержка его займет вообще минуты. Но, контейнеры ведь нельзя. Поэтому и Kubernetes - нельзя. Своего хранилища образов нет. Что остается? Сесть и переписать все на Vagrant и или Terraform. Виртуалки то по-прежнему можно. Ну и получается тянем боксы с открытого репозитория. Здравствуй безопасность. Теряем время на переделывание всего. Теряем время на запуск. Контейнеры стартуют минут за 3-5. Окружение на виртуалках стартует минут за 40.
Самостоятельная настройка tls сертификатов для виртуалок - тоже требует настройки, Vault - тоже сам прикрути. Или забей на все. Используй один пароль на все и отключи https.
Какой вариант имеет больше шансов?
Ну и плюс если нужно изменить настройки или что-то проверить в kubernetes, то сам же пошел и проверил. Если завязан на виртуалки, то сделал тикет и сиди жди пока до него кто-нибудь дойдет. Ты ждешь, рабочее время тикает.
Погодите. Тут ключевой вопрос. Тулинг для безопаснов не должен ограничиваться тулинг для всех остальных. Единственная действительная причина запретить инструмент всей компании в масштабах тысяч сотрудников - это доказана уязвимость в инструменте.
Подход - мне сложно это проверять или мне не принесли нужны молоток - тут не уместен. Проблемы 1-10 безопасников не стоят того чтобы делать проблемы тысячам других людей, забирая у них инструменты которые ускоряют работу.
Если контейнеры и Kubernetes снимают головную боль по ручной настройке и разворачиванию тестовых окружений, настройке сертификатов для tls, настройки паролей и ключей ssh. То безопасники должны придумать как предоставить всей компании сервис. А не говорить, нет нельзя контейнеры, копируйте ключи руками. Генерирует себя самоподписные сертификаты и вставляйте их везде где нужно. Это все приводит только к откату на обычный http, вместо https. И передаче единого палочки на все по чатам. Кому от этого лучше?
С таким товаром - нужны очень проверенные поставщики. Продажи - тоже вопрос специфический в этом сегменте. Я так понимаю стратегии не было никакой. Думаю было бы лучше расти очень медленно и на начальном этапе вообще вести бизнес в свободное от других дел время. Создать малый круг клиентов, и малый объем от проверенных поставщиков. И очень постепенно расти.
Конечно пандемия подкосила многие бизнесы и то что не закрылись в нее - уже достижение.
Меня конечно сейчас заплюют, но когда жене захотелось устриц поехали на соседний остров и набрали в море сами.
Лень нырять, в киоске на берегу можно взять порцию 3-4 евро.
А вы можете какое-то обоснование дать законности и своим выводам? Я думаю мем про дань и современные налоги всем известен. Что Чингисхан охренел бы узнав что можно брать не 10-20%, а 50-60%. А главное мне очень интересно посмотреть обоснование таких ставок. Вот я считаю 10-20% обоснованными, а выше - нет. Лучше на зарплатах депутатов и прочих высокооплачиваемых воров, сэкономить остальное. Ой простите, т.е. конечно же очень уважаемых и нужных людей без которых стране никак не выжить.
Если смотреть на одну из ситуаций - то скорее всего так и будет. Если смотреть на все полеты в целом, то это должно быть полностью на компьютере. У пилота есть более важные задачи во время полета, чем считать деньги.
Такая информация снижает когнитивные функции и отвлекает от более важной - состояния самолёта и окружающей среды.
Никогда такого не было и вот опять.
Эти ситуации делятся на 2 типа. Как с телевизорами и прочими устройствами, где экономят на флешке и тестировании совместимости. Такое был она телевизорах Samsung и камерах, пока они не вырезали Скайп. Они даже не делали свои камеры, но телевизор понимал ограниченный ряд разных производителей, но только на одно единственном чипе, чей драйвер положили в прошивку.
А другой случай, это вот Synology, когда компания ловит "свои" девайсы от жадности. Как картриджи для принтеров и прочие странные вещи.
Но есть действительно проблемы производителей чипов. Например те же сетевые карты сейчас опять же весьма криво поддерживаются в Linux, особенно WiFi. Производители чипов кладут делать нормальные драйвера и открывать документацию для других.
Поэтому использоваться ими в Линукс -- невозможно.
Я понимаю в командировке. А какие бывают срочные вопросы в разработке, что не могут подождать 20 минут пока вышел в садик/магазин?
Выглядит немного, странно. Вы вообще смотрели теорию информации и построение внутренних коммуникаций?
В чем современная проблема митингов? В том что менеджеры их используют для своего личного удобства, а не пользы компании. Как уже заметили выше можно просто посчитать, стоимость каждого митинга по ЗП. Но этого никто не делает. В больших компаниях, вроде Амазона, это все посчитано. Митинг просто так создать нельзя. Нужно писать объяснительную почему эти люди нужны. Это служит хорошим барьеров к чрезмерному росту ненужных митингов.
А вообще, проблема митингов решается комплексным подходом к распространению информации в компании.
Информация должна быть классифицирована, это во-первых. В зависимости от класса она должна быть передана устно, либо письменно. Потому что умная информация - это одноразово. Письменная - это навсегда и с большим удобством поиска и обработки. Голосовые сообщения - реально в работе никто не слушает и не будет. К тому же поиск по ним крайне сложный. Можно использовать ИИ для стенографии, но это все платно, а бизнес экономит.
Поэтому когда делают записи видео для передачи информации - это зло в этих фильмах потом невозможно ничего найти и для того что в тексте можно найти за секунды, приходится тратить часы на повторные просмотры видеозаписей. Да и скопировать пару строк текста из видео это не тривиальная задача.
Так что проблемы митингов, описаны и задокументированы и решаются вовсе не улучшениями инструментов для создания их большего количества и удобства.
Заставить информацию записывать.
Митинги без meeting notes - запретить.
Передавать информацию правильным путём. Критическую - только e-mail, быстрые вопросы - чат. brain storm - meeting с meeting notes.
Заставить сотрудников читать, всех, начиная с менеджеров. За вопрос без предварительной проверки в knowledge base - повторное прохождение тренинга по передаче информации внутри компании.
Когда компании начинают в политику - это встреча Титаника с айсбергом. Результаты будут видны в следующих сериях. Но шансы снова стать успешной стремительно тают.